concerns over wayland and need for wayland app display to X Server

[Bill Spitzak]

David Jackson wrote:

> If wayland API itself involves little more than sending pixmap or a 
> shared memory pixmap pointer from apps to a server, then the only option 
> it seems that would be feasible is to just send the pixmap data on to an 
> X server.

This is pretty much how it works.

Sending a pixmap is not going to be bad. First you have to realize that 
modern toolkits all render locally and send pixmaps, and they use XSHM 
and other stuff that was badly designed and was intended to send images 
that were about 128 pixels square for 1980's era desktops. A remove 
Wayland server will be designed knowing that the primary job is to 
transmit large pixmaps who's only purpose is to be viewed by the user 
and will be able to employ compression and other techniques to make this 
as fast as possible.

> If wayland API does not include a way that has the application telling 
> which areas have been updated through the API

Is there already some ideas for an updated region api that would be part 
of the attach? I don't see it in the protocol docs but I suppose it 
could be useful to speed up remote Wayland (though I also think a search 
for changed pixels won't be that bad, especially if it can be merged 
with the actual compression and streaming step).

> One possibility I suggested is designing the wayland client side API so 
> that client side wayland libraries/drivers which provide the wayland API 
> can be loaded at runtime as directed by a command line argument.By 
> default, the library for rendering to a real wayland display would be 
> loaded.

I thought it might just be a special wayland server that sends the 
pixmaps on to X11. The amount of code would be huge.

By far the biggest problem is getting the window borders right. My best 
guess is that a Wayland compositor will actually tell the client to not 
draw the borders (it needs this for fullscreen anyway). But the amount 
of crap a client needs to send to get a correct X11 border is huge and, 
rather than uglify Wayland's api to pipe this through, it might be 
better for the client to know it is talking to X11 and get a direct 
connection by which it can do ICCCM calls directly. But as soon as you 
start doing this, it gets more and more likely that the client/toolkit 
might as well know it is using X11.

Window stacking bugs are also going to hurt and will probably make 
Wayland clients that contain more than one non-popup window break on X11 
unless the X11 window managers are fixed to stop raising on click.

> if the wayland API does not support high level vector graphics that 
> itself makes me skeptical of wayland, to offload rendering to the GPU 
> requires a high level vector rendering API used by apps to send vector 
> graphics to the window system.

I think you fail to understand how modern graphics hardware works and 
how modern APIs including OpenGL work. Modern GPUs are perfectly capable 
of drawing into memory allocated by client programs (and all new designs 
are fixing it so this can be *any* memory and not special "graphics 
memory"). And the amount of data sent to the GPU is many times larger 
than the amount of data stored in the resulting pixels (for example a 
modern font contains tens of thousands of glyphs of which you may only 
draw 100 or so, a rendered 3D scene contains many more polygons than 
pixels, and images are often clipped or scaled so that the amount of 
data left in the window is much smaller than the image). Therefore it is 
more efficient to keep the image on the same machine as the client.