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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
