Freerunner and Wayland
neiljerram at gmail.com
Wed Jul 13 17:25:33 CEST 2011
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
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
More information about the community