On Wed, 23 Dec 2009 14:58:28 +0100 Helge Hafting <[email protected]> wrote:
> A bad driver can certainly make things slower. > > But the initial suggestion was to do "simplified" graphics > outside X, in the hope that it'd be faster without X overhead. If you're only talking about the X protocol overhead, then that's true - although I haven't yet seen any numbers... However, it's not the driver's fault. By the time (say) GTK's rendering instructions get to our driver (i.e. xf86-video-glamo), they've been turned into a series of tiny rectangle operations which are almost impossible to accelerate in any useful way. In this sense, the way X requires programs to send their rendering commands, and the way GTK/Cairo sends its commands, and the way the X server core communicates with the driver, are hurting us. Essentially, that's why E is so much faster: it prepares larger chunks of data at a higher level where acceleration can be much more meaningful, then sends them to the server in one big block. The price of this is that the acceleration done by the driver is hardly used in most cases, so we still don't get the best out of our hardware. A more fundamental redesign could potentially allow such pitfalls to be side-stepped, but this also comes at a price: Hardware-dependent code would end up existing at a higher level in the software [1], reducing the reusability of code. Tom [1] In the extreme case, hardware-dependent code can be moved all the way up the the individual client program, abstracted by a library. This is what DRI does, in which case that abstraction library is usually Mesa, providing an OpenGL API. -- Thomas White <[email protected]> _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
