Jason Tackaberry wrote:
> 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.
[...]
>> 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.
I'm taling about 320 _visible_ images. It is more than we need because
they are very small now. The grid only renders visible items, so 1000
files in a directory are no problem for the code. Only if you somehow
"zoom out" to see _all_ items you will get a problem.
>> 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.
I don't do much. Well, I also calculate what items I want to put
where. Besides that it is only object creation.
>> 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)?
Without the set_from_rgb_data it is around 0.09 seconds. Creating all
actors, connecting them, etc. This sums up to 1 grid with 320
container each with one image and one reflection. Oh, the test case I
have adds another group. So around 1300 objects all with rendering
except the image texture.
>> | 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?
This would move the image loading to the clutter loop. I don't like
that idea at all.
> 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()?
drops down from 0.7 to 0.2 seconds. Nice! Removing the additional
container and the reflection gives me 0.15 seconds. IMHO this is ok
for this task.
Dischi
--
One advantage of talking to yourself is that you know at least somebody's
listening.
-- Franklin P. Jones
-------------------------------------------------------------------------
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
