Display images with a least 10 fps
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Thu Jul 10 20:50:53 CEST 2008
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
> 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.
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the openmoko-devel