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 > [email protected] > https://mail.datenhain.de/mailman/listinfo/libavg-users > -- Any technology distinguishable from magic is insufficiently advanced. Ulrich von Zadow | +49-172-7872715 Jabber: [email protected] Skype: uzadow _______________________________________________ libavg-users mailing list [email protected] https://mail.datenhain.de/mailman/listinfo/libavg-users
