Display images with a least 10 fps

Carsten Haitzler (The Rasterman) raster at openmoko.org
Fri Jul 11 17:59:53 CEST 2008

On Fri, 11 Jul 2008 17:28:07 +0200 Timo Drick <timo at drick.de> babbled:

> 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?

basically "no". it wont help. you still need to upload the image pixels - one
way or another.

Carsten Haitzler (The Rasterman) <raster at openmoko.org>

More information about the openmoko-devel mailing list