Webcam support in Squeak (for VOLPC)

[salsaman]

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