On Wed, 2008-08-06 at 17:58 +0200, Dirk Meyer wrote: > 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.
I understand now. Well, even ignoring everything else, loading that many images from disk takes a second. We can't do better than that without preloading images, period. So as long as the grid provides some way to measure progress as it's loading that many images for presentation, the UI can provide a progress feedback. I think that's an acceptable risk. Though we can still work to optimize the other things. > > 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. What objects are being created? You mean candy objects? > 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. The most valuable metric we can have at this point is how much time is spent inside clutter. Subtract that from the time, and what's left is what we're responsible for. (This assumes we're actually _using_ clutter in the most optimal way.) Still, 0.09s to prepare 1300 objects isn't a tragedy of performance. > > 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. Yes, fair enough. But you can use gtk.gdk.pixbuf_new_from_file() in a separate thread, and then use clutter.texture_new_from_pixbuf() later. The reason I ask is that I believe gdkpixbuf's native colorspace is RGB32, and most importantly the same colorspace as GL texture. If clutter does the BGRA to RGBA conversion in software (as opposed to a shader) then you should be able to drop the 0.2 seconds further. gdkpixbuf loads slower than imlib, but if the overall operation of loading plus getting that data into a texture is faster, it makes sense to use gdkpixbuf. 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
