On Wed, 2008-08-06 at 17:22 +0200, Dirk Meyer wrote:
> I created a bad test case by updating the beacon test. I create a grid
> with thumbnails from around 320 (!) beacon items incl. a reflection.
My general reaction is that you shouldn't be processing all objects up
front. Defer what's off screen until you need it.
I have some directories with well over 1000 images. It's not acceptable
to wait some seconds before I can see the first few images in the grid.
By deferring, you make things arbitrarily scalable. There is no other
realistic way to solve the problem: optimizing only goes so far.
> 0.09 seconds to create all python objects. This includes getting the
> Thumbnail object from beacon and the filename of the thumbnail in the
> ~/.thumbnails directory. Without beacon it is around 0.06 seconds. No
> clutter objects are created.
This seems like too much time, but it doesn't account for a large enough
percentage of the overall operation to worry about it right now.
> 0.9 seconds (!) to load all thumbnails (256x256 pixel) using
> kaa.imlib2. This only uses _Imlib2.open internally so I don't think we
> can ever speed this up. Ideas welcome.
Yes, that's about right. Not much we can do about that.
> 0.7 second (!) to create all clutter actors and render what we
> need. Without the reflection it takes 0.6 seconds. I'm sure the huge
> problem is transforming the imlib2 image to clutter:
How much just to create the actors (without rendering)?
> | clutterobj.set_from_rgb_data(imlib2obj.get_raw_data('RGBA'), True,
> | imlib2obj.width, imlib2obj.height, 1, 4, 0)
What is the speed difference if you use clutter.texture_new_from_file?
How much time does it take to execute the above quoted call for 350
images? get_raw_data('RGBA') is not going to be fast, as the colorspace
conversion (from BGRA) happens in C (albeit a tight loop, but there's
only so fast that can get).
What happens instead if you do get_raw_data() (no arguments) and pass
clutter.TEXTURE_RGB_FLAG_BGR to the last parameter of
set_from_rgb_data()?
> This has to be faster somehow. I know that 320 images are more than we
> will ever need, but it is a good test case to find bottlenecks.
If the grid widget is to be used in browsing through images, DVD covers,
etc., 320 is nowhere near more than we'll ever need.
Jason.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
