[libavg-users] Adding images inside a frame handler

[Ulrich von Zadow]

On Jan 3, 2010, at 5:26 AM, Alex Harrington wrote:
>
>> Is it possible that you are exhausting
>> GPU memory? GPU mem needed is width x height x 4 bytes for each  
>> image,
>> and all images actually in the avg tree are uploaded into GPU memory.
>
> I have 512MB on my graphics card. The big problem image uses about  
> 20MB by my calculations. Assuming the bitmaps for nodes that have  
> been deleted are freed from video memory then I don't think there's  
> sufficient data to fill the RAM on the graphics card.

You can make sure that nodes are being deleted by calling  
TestHelper.dumpObjects and looking at the number of nodes allocated.

>> On the other hand, you can try loading the image file into a bitmap
>> object in another thread and use image.setBitmap() in the main  
>> thread.
>> I can't promise this will work out of the box (libavg isn't meant to
>> be threadsafe), but if any problems crop up, I'll look into them.
>> Changing the avg scene graph directly from a second thread will
>> definitely not work.
>
> I've hacked bits out of the client app in to a simple test case  
> which I've put here: http://dl.dropbox.com/u/58386/libavg- 
> image.tar.gz mainly to make sure it's not something in my code  
> causing the display thread to block.

 From what you're writing, I really think you should look at loading  
the bitmap in a secondary thread.

Cheers,

   Uli

> It's marginally quicker outside the client (which isn't that  
> surprising given there's no other activity going on in other threads  
> behind the scenes). Here's the relevant output from that test app:
>
> 1262492626.54 FH IN
> 1262492626.54 *** ADD IN: R4a61ede591a21-11 ***
> 1262492626.89 *** ADD OUT: <image href="data/10.jpg" id="BIG-IMAGE"  
> opacity="0" /> ***
> 1262492626.89 FH OUT
> <SNIP>
> 1262492627.07 FH IN
> 1262492627.07 *** ADD IN: R4a61ede591a21-11 ***
> 1262492627.08 *** ADD OUT: <image href="data/10-gimp.jpg" id="SCALED- 
> IMAGE" opacity="0" /> ***
> 1262492627.08 FH OUT
>
> It's really clear there that adding a much smaller image is alot  
> faster than adding the original - so I guess that's where the  
> problem lies.
>
> I can look at prescaling the image files before display but that  
> gets messy as the same image can be reused over and over at  
> different sizes at present.
>
> Alex
>
> This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer
>
> _______________________________________________
> libavg-users mailing list
> libavg-users at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-users
>

--
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow