Hi Tom, Thanks for your answer...
On 13 July 2011 10:01, Thomas White <t...@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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community