Qtopia coming for Neo1973

[thomas.cooksey at bt.com]

>As long as X11 renders to FB, that's true. However, with the GPU in GTA02 that 
>may not be true at all as in fact, Mickey mentioned on IRC yesterday that fb 
>operations may well be *slower* on GTA02 than on GTA01.
>
>I don't know enough about the differences between Qt and Qtopia (aside of the 
>fact that Qtopia draws to the fb directly), but if Qtopia app scan run on Qt, 
>we might well end up seeing that on GTA02 as Qt/X11 will get the GPU 
>acceleration for "free"? At that point, GTK and Qt(opia) could happily 
>coexist like they do on the desktop.

What acceleration? You don't get hardware acceleration for free. Just because there's hardware there to accelerate drawing operations doesn't mean it gets used. I have raised this question several times:

> > What kind of driver are you planning on?  (I don't think I saw that
> > answered yet, sorry if I missed it)  KDrive, DRI, etc...
>
> We don't disclose this information yet, sorry.  As soon as there is
> something working, it will be in our subversion, though.

That reply came from Harold of all people. Surely it goes against the ideals of OpenMoko?

I guess the main reason I'm for a Qtopia based framework over a GTK+/X framework is the technology and the ease of accelerating drawing operations. I've spent a lot of time trying to understand how Linux graphics stacks work. Now, Qtopia seems highly integrated (and much simpler as a result). It is also exceptionally well documented thanks to doc.trolltech.com. X on the other hand seems mind-blowingly complicated and I have really struggled to understand how it works. Documentation is apauling and I can't even find any decent books on how it works. But, I will now try and explain how I understand it works and please, PLEASE correct me where I'm wrong! :-)

X is client server architecture which uses sockets. The server draws things on behalf of the clients. Rather than clients having to understand the X protocol, Xlib was developed to provide a drawing API. XLib is a very limited API for drawing lines, rectangles and arcs. XLib also allows clients to send a pixmap to the server to render. As time went on, line rectangles and arcs became a bit limiting so toolkits like GTK started rendering vector graphics into pixmaps and just used XLib to send those pixmaps to the server. Copying pixmaps over sockets was slow so shared memory was used instead for local clients. Pretty soon a more advanced vector graphics API was needed and so Cairo was born. Cairo rasterizes vector graphics into a client-side pixmap which is then drawn onto the screen using XRender, allowing compositing. Soon, people wanted anti-aliased, scaleable text, which XLib couldn't provide and so Pango was born. Pango uses Cairo to render text allowing both vector graphics and text to appear together. Pango, Cairo & XLib are wrapped up in the GDK (The API of which is pretty well documented at http://library.gnome.org/devel/gdk/index.html). GTK+ widgets are rendered using a theme engine, which uses the GDK to render widgets. I.e. An application defines a widget, a theme engine draws that widget via GDK. That could be rendered using GDK's wrappers for XLib or cairo (typically cairo for desktops).

So that's how I understand GTK/Cairo/Pango/X hangs together, but as I said before others know far more than I do. ;-)

Now, given that is how the graphics stack hangs together, where do you off-load operations to hardware? What operations _can_ you off load to hardware? From what I've read, the most computationally expensive operations are ones which involve accessing large blocks of memory, e.g. block fills & block copies. These typically can be performed by hardware. So, when you drag a window round the screen, hardware can be used to copy the window to it's new location. Block fills & block copies are the only operations (other than cursors) most hardware accelerated x servers implement, which is fine, because that's where most of the work is. I mentioned earlier that cairo uses Xrender to copy & compose rasterized graphics onto the screen. Some graphics hardware can accelerate some of the XRender operations, however, in X.org it seems the current driver model makes that very difficult, resulting in limited acceleration and thus slowness (different drivers accelerate different XRender operations). To fix that, Glitz was created to allow cairo to render to a GL context and use the 3D hardware to accelerate the composition, sidestepping XRender completely.

Lets look at OpenMoko's rendering path. Thomas Wood mentioned yesterday, OpenMoko currently uses a pixmap based theme engine. The pixmaps are (IMO) beautiful. They are all shiny and curved and have a nice orange-black gradient. While they look great, they are slow as the pixmaps need to be copied from off-screen buffers to the frame buffer. My guess is that's why the OpenMoko interface is a bit slugish (only a guess, I suspect others on this list know a lot more about this than I do!). Thomas mentioned yesterday that the new theme engine for OpenMoko used XLib (though GDK) rather than pixmaps or cairo. That's going to be much faster because there are no big copies involved. However, I don't understand how using XLib is going to produce the same graphical results. There's no facility for doing gradients or shadows or anything pretty? 

The GTA02 will have an SMedia grapgics accelerator. As it's not been disclosed how the SMedia chip is going to be used, I have to guess and my guess is that a KDrive server will be written which will accelerate block fills and block copies. That's going to speed up the pixmap theme engine a lot because the pixmaps are copied from the off-screen buffers to the framebuffer by the graphics hardware. However, the SMedia chip can do a lot more than just accelerate block copies and as far as I can tell, there's no real way of using it's features with X.

On the other hand, we have Qtopia. In Qtopia, an application defines QT Widgets, which are drawn using a QPaintEngine into an off-screen buffer then copied to the frame buffer using a QScreen. Writing an accelerated graphics driver is as simple as inheriting from QPaintEngine & QScreen and re-implementing the methods the hardware has acceleration for and leaving the other methods alone for software fallback. The process of writing an accelerated driver is also very well documented with some great examples to use.

The drawing API of QPainter (http://doc.trolltech.com/4.3/qpainter.html) is _so_ much more powerful than XLib (it lets you do gradiants for example!) To get a similar level of drawing API for GTK, you have to use Cairo, which as the benchmarks I posted show, is a lot slower than QT, and is nearly imposible to accelerate in hardware.

Again, I don't pretend to be an expert, but this is just what my understanding is.


Cheers,

Tom


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6194 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/community/attachments/20070919/1adc7725/attachment.bin