Dan Williams wrote:
On Wed, 2007-03-07 at 19:38 +0100, salsaman wrote:
Dan Williams wrote:
If you send X a pixmap that's not in the native framebuffer format
(which happens to be 565 right now) then X will have to format convert
that to 565 for you, which ends up being really slow, especially for
large pixmaps. The moral of the story is, don't format convert, and
keep everything you want to be fast in native framebuffer (ie 565)
format.
Well, that could be a big problem for LiVES (and for any other
application using GTK+/GDK). LiVES uses RGB24 as its internal format.
Why the heck use 16bit colour for the X server ? Why not use 24bit like
the rest of the modern world ;-) ?
Because then you have to push around a lot more data, and you loose
about 6MB _more_ of memory to VRAM than we already loose. Plus, it's
unclear whether 888 is really a win. You gain because you don't have to
format convert, but you loose because the pixmaps are much larger. We
don't have a ton of memory bandwidth, and we're memory limited anyway.
The pixmaps will be the same size anyway, because GdkPixbuf uses RGB24.
We have explored going to 888 but there wasn't time to do real
performance measurements to make sure that 888 wasn't a regression in
the general case.
We also explored going to 4444 or 1555 to make format conversions
unecessary when alpha was being used, but that will take some work in X
and cairo that we don't have time to do.
Simply put, the Geode GX processor is not a very fast processor, and the
GPU has known limitations. Using the GX was a choice that was made
based on tradeoffs of price vs. performance and we may just have to live
with the limitations.
If existing applications don't respect the limitations of OLPC, then
either they must be fixed to do so, or they will not be performant.
Dan
"Must be fixed to do so" !?
It's not possible to use RGB565 in LiVES for a variety of reasons: it
uses GDK, which only supports 24/32 bit colour; and RGB565 is not a
supported palette in any of the modern video processing standards (the
only application which I know supports it internally is MOB, and I
believe is dropping it soon, or may already have).
We (video developers) decided about 2 years ago to drop RGB565 support
in Livido (the now becoming common effect standard)
http://livido.dyne.org/ and hence it is not present either in Weed
(LiVES' own effect standard which is based on Livido).
In short, supporting RGB565 in LiVES would require several man-years of
work to make a hacked version of GDK, followed by several months of work
to alter LiVES, plus rewriting all of the effect standards. Even then,
since most effects process in RGB24, it would require a lot of palette
conversions internally.
I am not even sure if LiVES will run on a 16 bit display, AFAIK this has
never been tested.
A really don't see what you lose going to a 24 bit Xserver. Sure, it
needs a bit more memory, but for a 1024x768 screen resolution, you are
only talking about 800KB more.
I think a lot of applications will have problems if you stick to 16 bit
colour. Just my opinion though.
Regards,
Gabriel.
http://lives.sourceforge.net
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
