Display images with a least 10 fps

[Timo Drick]

Carsten Haitzler (The Rasterman) schrieb:
> On Thu, 10 Jul 2008 18:12:32 +0200 timo <timo at drick.de> babbled:
>
>   
>> .....
>>     
>>> how big are they? (the images - in pixels)?
>>>
>>> --
>>> Carsten Haitzler (The Rasterman) <raster at openmoko.org>
>>>       
>> I would like to have fullscreen display. The images i want to display are
>> 320x240 or 640x480 with jpeg compression.
>> But the compression is not the problem which you can see at my example. It
>> just scale the unkompressed image and display it.
>> But i think the GtkImage widget do not have a good performance for
>> animation. 
>>
>> I will give the libsdl a chance the next days.
>> If anyone have a better idea plz tell me.
>>     
>
> ok. you basically have hardware limitations. let me ignore the disk IO needed
> to load the file off disk, and the cpu required to decode the jpeg, then the
> need to convert it to 16bit color (as the jpeg wil be decode in 24bit by
> libjpeg). i suspect you can possibly load and decode 640x480 jpegs about 5-10fps
> - but not a lot more. maybe even a bit less. BUT even if you already had all
> decoded into ram... there is bus limitations on the glamo graphics chip. if
> you spent 100% of cpu ONLY on uploading pixels to the glamo you would get about
> 11-12fps of 640x480 images giving the 7mb/s of bandwidth to the video card. (you
> can do the math). that means 0% cpu left to load, decode and convert the images
> to 16bit color (unless you do this in advance and fill ram with the images).
> remember also that flash is not fast. i have measured about 2mb/sec "disk io"
> read rates from flash (not much different from micro-sd). so you will be
> waiting on disk io to read the jpeg data, then need to decode it, convert to
> 16bit, upload to the screen.
>
> so as such i suspect 2-3fps is all you will ever get. even given a very
> optimised pipeline. you basically have what is not a very fast cpu (it may be
> 400mhz, but the memory is single-datarate at 100mhz), and io bottleneck from
> cpu/ram to video ram.
>
> as mickey said - evas can do this too. it has probably one of the best
> optimised generic image rendering pipelines around - especially for software.
> it's not perfect, but it's one of the better options. and even it will hit the
> above limits. in fact it consistently gets about 2.3fps. it's hitting the same
> limits. even my own test app hits that limit... UNLESS it can keep all jpegs in
> ram. if it can keep all in pre-converted 16bit color i can squeeze about
> 11.5fps - which is bus bandwidth limits on the glamo. if it has to convert from
> 32bpp to 16bpp each time, it is still managing 5.7fps. so as such the overhead
> to load the jpeg takes u from 5.7fps to 2.3fps (if u can jeep the jpeg already
> decoded in ram) if u can avoid the 32bit->16bit conversion u can go up again to
> 11.5fps - but ALL you do is copy images up to screen. nothing else. all cpu
> time is spent uploading pixels.
>
> so basically.. you're about as fast as it gets on the freerunner.
>
>   
Ok thanks for the detailed explanation. This save much testing time for 
me and searching for other solutions.
The disk io is not my problem because the images streamed over network. 
But i am not able to avoid the decoding and 16 bit resampling. So i have 
to use smaller image and display size.

Is there a chance that the cpu usage for the transfer from ram to video 
ram could be decreased if the video 3d acceleration is working?

regards Timo