On Fri, 11 Jul 2008 17:28:07 +0200 Timo Drick <[EMAIL PROTECTED]> babbled:
> Carsten Haitzler (The Rasterman) schrieb: > > On Thu, 10 Jul 2008 18:12:32 +0200 timo <[EMAIL PROTECTED]> babbled: > > > > > >> ..... > >> > >>> how big are they? (the images - in pixels)? > >>> > >>> -- > >>> Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> > >>> > >> 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) <[EMAIL PROTECTED]>
