Announcement

Collapse
No announcement yet.

The Wayland Situation: Facts About X vs. Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dee.
    replied
    Originally posted by curaga View Post
    Pango depends on the backend: cairo and FT go to images, Xft backend text.

    Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

    However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.
    The question is, why? Why would toolkits want to go back to the old way of doing things, do you think they just one day decided "hey, let's start bypassing the X drawing API for no particular reason"? The reason they stopped using the API is just as valid today as it was then.

    GTK3 already has a HTML5 backend (or it's in development, or something). I'm pretty sure Qt could (if it hasn't already) develop something similar, and EFL as well. There's no point in forcing every app to use some kind of archaic drawing API because what about things like SDL, or apps that only play video and don't need any (or only minimal) UI, or games...? Those would have no need whatsoever to go through the extra overhead of a drawing API. And no matter how you implement it, it's extra overhead, and you'll have to allow direct-rendering in some form or other (in order to allow video playback, among other things), which means, the toolkits would just continue bypassing it and nothing would change.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by curaga View Post
    Pango depends on the backend: cairo and FT go to images, Xft backend text.

    Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

    However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.
    Then do not invent a protocol for each, but a shared drawing standard. The thing is, when you make a monolithic specification, you'll then have to drag behind you the legacy functionality for things unrelated to your actual concern, and they get in the way. If toolkit people feel they need a standard for drawing so they can draw over the net and such, they could make a platform independent drawing protocol, which would be able to run over Wayland and get dropped later if needed without having Wayland needing to carry their mistakes for backwards compatibility. Again, Wayland does the buffer management. You can tell Wayland to create surfaces of given dimensions in both sides and a compositor to deal with them, and send commands to the drawing protocol to modify them in the wanted end.
    But considering toolkit's people didn't either use X facilities for that or make their own specification for drawing, chances are there is not enough interest, and it's already running the inefficient way, which means there's no real loss in that aspect from switching to Wayland.
    Last edited by mrugiero; 09 June 2013, 06:59 PM. Reason: Reformulate an ambiguous phrase.

    Leave a comment:


  • curaga
    replied
    Pango depends on the backend: cairo and FT go to images, Xft backend text.

    Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

    However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.

    Leave a comment:


  • curaga
    replied
    Qt 4 draws into a bitmap first, so for anything Qt text remoting would indeed not work.

    Leave a comment:


  • curaga
    replied
    Originally posted by nzjrs View Post
    Thus proving daniels (and the other wayland/x11 developers point). They actually know the details of the domain in which they are hacking.

    You are arguing from ignorance. How about we trust their experience and technical acumen a little?
    Proving what? It proves my point that there exists at least one toolkit that does it properly.

    Leave a comment:


  • nzjrs
    replied
    Originally posted by curaga View Post
    The only toolkit whose internals I'm familiar with is FLTK. It certainly draws text using the Xft API, not into a picture that is then blitted.
    Thus proving daniels (and the other wayland/x11 developers point). They actually know the details of the domain in which they are hacking.

    You are arguing from ignorance. How about we trust their experience and technical acumen a little?

    I cant believe I bothered to comment. God I hate the internet.

    Leave a comment:


  • garegin
    replied
    Originally posted by daniels View Post
    it totally makes sense, but all the drawing is totally toolkit-specific, hence our suggestion to do this kind of thing at the toolkit level instead.
    thanks for the clarification. is this being done, though, anywhere? windows, haiku, gtk ...

    Leave a comment:


  • curaga
    replied
    Originally posted by daniels View Post
    no, they all send massive pre-composed images for almost everything.
    The only toolkit whose internals I'm familiar with is FLTK. It certainly draws text using the Xft API, not into a picture that is then blitted.

    Leave a comment:


  • daniels
    replied
    Originally posted by curaga View Post
    Thanks for clarifying the official position. I get you don't want this repeated, but it's kind of hard to believe you're willingly throwing away a platform advantage, and a set of users with it.
    i don't think we are. x11 leans heavily enough on huge window-sized images that i don't buy wayland's client-side-only rendering as a regression from it.

    compared to a hypothetical strawman window system, i guess it's a regression, but then everything's a compromise when your competition has the luxury of not having to exist in the real world.

    Leave a comment:


  • daniels
    replied
    Originally posted by garegin View Post
    Daniel. I am a noob in graphics, so please bear with me.
    Isn't remote rendering something like MIDI or font equivalent for GUI? By that I mean, instead of sending compressed images down the wire you tell the remote computer the "elements" like window borders or buttons and then the client just retrieves them from a local source.
    Makes sense to me if you have a unified GUI like in Windows or OS X. Is this already being done in MS's RDP. Or is such a bad idea that no-one does it.
    it totally makes sense, but all the drawing is totally toolkit-specific, hence our suggestion to do this kind of thing at the toolkit level instead.

    Leave a comment:

Working...
X