Wayland's Weston Now Handles Full-Screen X Windows

[renox]

But currently with remote X applications for each glyph draw you are chatting to and and from the X server for that server side draw operation right?
[cut]Waylands "remoting" isn't fixed in stone so it's a little early to tell, but I think the gnashing of teeth is a little pre-emptive, to be honest.

Totally wrong, in one X request you can draw several things.
As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..

[JS987]

Totally wrong, in one X request you can draw several things.
As for Wayland remoting, adding an XRender's style operator on top of current Wayland's operation would be a major design change..

Wayland should support server side rendering by linking with freetype, cairo, pango, etc.

[curaga]

GLAMOUR takes a rendering model that is inherently antagonistic to how modern GPUs work and tries to mske it fast. Toolkits need to intelligently render their widget graphs in a GPU-efficient manner, not use bad 2D APIS with some expectation of a lower level making it all right. I think Qt is moving there; GTK has a lot of work to do. To be fair though Windows' myriad of toolkits are generally just as bad; even ones using D2D generally use it wrong and end up slower than CPU-based rendering in many cases. Even many games just use Scaleform, which is helluva inefficient compared to what a knowledgeable dev with enough time/budget can do.

GPUs are all about minimizing state changes and batching draw calls. Rendering many individual "primitive" 2D elements and using non-atlased pixmaps/glyphs is just bad. The lower layers can do some auto-magic batching, but the toolkit can do way more, and can expose a more appropriate drawing API to apps/themes. Clutter hence is way more interesting than GLAMOUR.

While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.

[pq__]

He's referring to compositing in the terms of desktop effects. Which in reality what he's referring to is Indirect Rendering.

Indirect Rendering:

Input -> X Server -> X Client -> X Server -> Compositor -> X Server -> Image is displayed

Direct Rendering:

Input -> X Server -> X Client -> X Server -> image is displayed

Wayland Rendering:

Input -> Wayland Server -> Wayland Client -> Wayland Server -> Image is displayed

Since the Wayland Server IS the compositor (kwin, mutter, compiz) There's no performance drop unless they hit a slow code-path or bug in the compositor.

With indirect rendering there's a slow down (What he's talking about), with Direct rendering there's no slowdown. And with Wayland rendering there may even be a speedup in rendering time, and therefore better FPS, because they dont have to work around all of X's bloat and cruft and legacy crap.

No, you are not describing indirect rendering here. All cases you describe can equally well be direct or indirect rendering, since you (nor I) ever mention who does the actual rendering of the client's image: the client or the X server. We were just talking about client provided images, not how they are originally created.

Compositing or desktop effects have nothing to do with indirect rendering.

The compositing manager in X might be (have been? Wasn't this limitation lifted?) limited to use indirect rendering for its own rendering only, but that has nothing to do with normal X clients.

But that one is true that Wayland has less overhead: no indirect rendering (because all clients render full frames themselves, not pushing rendering commands to a server), and no communication with a third process (compositing happens within the server).

Disabled compositing - direct rendering using overlay.
Wayland doesn't support overlays, but it seems it will be fixed.
http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.

Wayland should support server side rendering by linking with freetype, cairo, pango, etc.

This comment makes no sense on its own. You would have to invent also a rendering protocol, which is an unimaginably hard task to do well.

[renox]

While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.

1) Not all applications do this kind of rendering.
2) You can cache several different glyphs for one character..
I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
The hard part is handling resynchronisation in case the server needs to reduce the cache size..

[JS987]

Your comment makes no sense. All rendering on Wayland is always direct rendering. There is no indirect rendering, because Wayland does not have a rendering protocol.

Wayland without overlays does compositing using GL, which causes rendering to be indirect.

The addition of atomic page flip to the kernel should allow the configuration of overlays within a frame boundary. This allows KMS Wayland compositors, such as Weston, to use overlays seamlessly. In this talk we'll cover how Weston assigns different surfaces to overlays and other planes, to reduce the portion of the screen that is composited using GL.

http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

[silix]

Wayland without overlays does compositing using GL, which causes rendering to be indirect.

http://www.phoronix.com/scan.php?pag...tem&px=MTI5NTE

two pass rendering != indirect rendering

GL indirect rendering means that the application is unable to talk to graphic hardware - thus GL calls have to be submitted to the server which in turn submit them to the gpu (as it's the only one with hw access privilieges) - hence AIGLX

compositing means that an application IS able to operate on the gpu (within the device context it has been assigned), hence direct rendering - but since only the compositor/wm/server knows about windows from ALL active applications, they render offscreen textures that the compositor then renders on screen
hence a 2 pass rendering, or redirected (direct) rendering

which may have some overhead over rendering directly to screen in a single pass, but if you think about it the latter would apply only to full screen applications and overlays

[curaga]

1) Not all applications do this kind of rendering.
2) You can cache several different glyphs for one character..
I think that the ideal solution would be to have a 'duplicated identical cache' between the client and the server: at first the client and the server agree on a cache size (empty at the beginning), then the client send glyphs which are stored both in the client and the server cache, client and server use *identical* algorithm to manage the cache, so when a client see that a glyph is in its cache it knows that the server also has it in its cache and then it can send only a draw this glyphs references.
The hard part is handling resynchronisation in case the server needs to reduce the cache size..

It's not enough to cache several iterations of some letter. They can also overlap (and the overlap can change just as the shape) and can change dynamically, meaning you would have to cache the overlap data, and with the possibility of per-letter changes, the amount of permutations becomes rather unwieldy.

[JS987]

While true, you simply cannot do that with modern text rendering. Truetype font glyphs can change their shape depending on what glyph is next to them.

So trying to cache individual glyphs in one texture will result in ugly and unexpected text rendering.

For Arial one texture per font size is enough.
http://imageshack.us/photo/my-images...rendering.png/
click image to view in original size

[JS987]

two pass rendering != indirect rendering

2 pass rendering is indirect rendering.