Re: [Gumstix-users] touchscreen calibration & best color support?

[Tom C. <tho...@tr...>]

> I'm sorry for passing on bad information!!!
No problem - I'm just relieved it's a mis-understanding rather than a bug!


> >  > > whats the best workaround
> >  > >  now after installing the gumstix-x11-image to have a usable gui?
> >  > > would it be best
> >  > >  to compile qtopia and forget the gumstix-oe matchbox? has it the
> >  > > same problem?
> >  > >  i'm sorry if this question is trivial i'm a non-experienced user

Short answer: 
* X11 stack may not ever work properly with 18bpp
* Qtopia Core currently (4.3) works but is a bit slow (Still very usable 
though!)
* Qtopia Core 4.4 _should_ have better performance on 18bpp LCDs


Long answer:

> I misunderstood your previous comments about needing to develop an 18
> bit backing store as meaning that the current version didn't work.  I
> didn't realize that it was just a performance issue.
Yep, the only issue is performance. Qtopia Core has had 18-bit support for a 
while. It is currently implemented so that all drawing is done in 24-bit 
(32-bit if there's an alpha channel) into off-screen backing store buffers. 
It is then converted from 24-bit to 18-bit just before it is copied to the 
frame buffer. This has the following drawbacks:

1) You _have_ to use a acking store - there's no way to render directly into 
the framebuffer (the QWS_DrawOnScreen flag doesn't do anything).
2) All the drawing routines are operating on a higher precision pixel format 
(theoretically taking more CPU cycles to render), which is then thrown away 
at the last moment. I.e. CPU cycles are wasted by rendering at a higher 
quality than the screen can display.
3) Qtopia's internal buffers use 25% more memory than they need to
4) Every screen update needs to do a pixel-by-pixel conversion from 24-bit to 
18-bit - which is again eating more of your precious CPU cycles.

So, that's why 18-bit is currently slow. In 4.4, the entire rendering path is 
18-bit, eliminating all of these issues. :-)


> I thought the issues were similar to x11 where the core package
> supported 18bpp, but renderers for  fonts, icons, & such didn't
> support 18bpp all that well and resulted in ugly screens.

<Biast Trolltech Employee Opinion>
18bpp on Qtopia Core currently works well (apart from performance) because 
everything is rendered in 24-bit into a backing store, and then converted in 
one place, before the copy to the framebuffer. I'm no expert, but I believe 
X11 (or more specifically, the LinuxFB driver for KDrive) renders stuff 
directly into the framebuffer, bypassing a backing store. This means, as you 
say, everything which does rendering has to support rendering in 18-bit. As 
there are so many different ways to get pixels on the screen with X11, making 
everything work with 18-bit is a bit of a nightmare and probably not going to 
happen (e.g. even if 18-bit pixel formats are added to the server, Cairo, 
Pango etc. etc. need to be modified to support the new pixel format).

Like I say, the complete rendering path in 4.4 is 18-bit, which includes 
complex 2D paths, text, etc. It was easier for us to make this change in 
Qtopia Core because the complete rendering path (Widget->Style->2D 
Rendering->Window System->Window composition->Hardware framebuffer) is in one 
code base.

On X11, the path looks a bit like this: GTK+ Widget->GTK+ Theme Engine->Cairo 
& Pango->XLib/XRender->Kdrive->Matchbox->KDrive LinuxFB driver. This path is 
made up of 4-6 different code bases, all with their own communities, 
developers & objectives.

</Biast Trolltech Employee Opinion>


Cheers,

Tom