Jason Tackaberry wrote: > 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.
Agreed. > 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. The grid is a special case where it would not matter if the images are loaded by a thread and they pop up after each other. But in normal operation I want to see an image _now_. >> > 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? Yes >> 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. Agreed >> > 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. Isn't texture_new_from_pixbuf a clutter 0.6 feature dropped in 0.8? > 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. I will try to replace the imlib2 code with pixbuf and we will see. But it is late now, I will do this tomorrow. But this is only a stupid performance test, loading 320 images at once and creating 1300 candy _and_ clutter objects isn't daily use. I just wanted to test if kaa.candy scales to avoid the problems we had with kaa.canvas and the tv guide grid taking too much time. Dischi -- Diplomat: A man who always remembers a woman's birthday but never remembers her age. ------------------------------------------------------------------------- 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
