Freerunner and Wayland

Neil Jerram neiljerram at gmail.com
Wed Jul 13 17:25:33 CEST 2011


Hi Tom,

Thanks for your answer...

On 13 July 2011 10:01, Thomas White <taw at bitwiz.org.uk> wrote:

> acceleration pathways.  A lot of the performance difficulties with the
> X pathway (not just on our hardware) seem to be because the server
> can't possibly know enough about what the client wants to accelerate it
> effectively. Fast and smooth graphics on the Freerunner should be
> perfectly possible, but would rely on exactly this kind of
> "clairvoyance" from the X server.
>
> So, getting Wayland to run on its own shouldn't be too difficult
> (famous last words..), but writing programs which can actually make use
> of it is significantly more difficult.

I have read that some toolkits, like Gtk+ and Cairo, have (or are in
the process of having) support for Wayland as their backend directly
(i.e. not via X).  Also that it's possible to write clients using a GL
API directly, and that the library providing that API would use
Wayland directly.

I guessed from that that the toolkit or GL implementation might be in
a better position to have exactly that kind of clairvoyance - i.e. to
know what kind of acceleration would be useful, and to ask the
hardware driver for that.

Hence, I thought, there might be some performance benefit in the
acceleration-potential being in the toolkit or library, instead of in
X; and also perhaps in just cutting out one of the layers.  Also, I
presume, I could write a new client today using e.g. the Cairo API,
and that should Just Work.

Is any of that correct?

(Having said that, I don't recall reading yet of any Wayland support
in the E toolkit, and certainly that would be a specific problem for
SHR usage.  But maybe Wayland is still worth experimenting with in a
non-SHR setup.)

Thanks again,
       Neil



More information about the community mailing list