Re: [Freevo-devel] kaa.candy changes proposal
2008/8/7 Jason Tackaberry [EMAIL PROTECTED]: On Wed, 2008-08-06 at 23:41 +0200, Dirk Meyer wrote: 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_. At least for the actual UI (menus and such), any such images can be preloaded, at startup or something, since we'll know what images are in use based on the theme. Hi Guys, been a while.. Aren't we talking about another scenario though? The menu itself is static but the scenario of having say a USB based hard-disk full of media that plugged in after load? I know I'm skipping here but even if there was an image cache you woudn't want that kind of content pre-loaded would you? I much preffer the idea of having UI feedback telling me that my images are loading and what status the load is at as long as it doesn't block my ability to control the UI navigation I'm in a hurry.. Mick - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
On Mon, 2008-09-08 at 17:29 +0800, mike lewis wrote: Aren't we talking about another scenario though? The menu itself is static but the scenario of having say a USB based hard-disk full of media that plugged in after load? I know I'm skipping here but even if there was an image cache you woudn't want that kind of content pre-loaded would you? No, I wouldn't think it sane to preload anything except UI elements. At least not preload in the same sense that I referred to earlier. What I would expect to do is read-ahead 1 or 2 images when you begin viewing images in a directory. as long as it doesn't block my ability to control the UI navigation I'm in a hurry.. dischi and I are of one mind when it comes to responsiveness of the UI: most kinds of UI blocking are unacceptable. The API we have in kaa lends itself very heavily to asynchronous design. So for 2.x you shouldn't worry too much about UI blocking. At least not the obvious blocking that can be avoided. Certain things are unavoidable. If we need to load 20 images to display a menu and you've opened that menu, the time it takes to process those images and render the menu is necessarily going to block the UI. It's a design goal to make such things 100ms. I think in most cases we're well under that. (But dischi knows the GUI side of things better than I do right now.) - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
mike lewis wrote: Aren't we talking about another scenario though? The menu itself is static but the scenario of having say a USB based hard-disk full of media that plugged in after load? I know I'm skipping here but even if there was an image cache you woudn't want that kind of content pre-loaded would you? I much preffer the idea of having UI feedback telling me that my images are loading and what status the load is at as long as it doesn't block my ability to control the UI navigation I'm in a hurry.. Not sure I understand what you mean, but the basic idea is: 1. You enter the directory 2. kaa.beacon does a quick 'ls', no metadata?/thumbnails 3. Freevo shows the menu with the information it has 4. beacon scans the directory and creates thumbnails in the background 5. Freevo updates from time to time Dischi -- Hard work never killed anyone, but why give it a chance? - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
Jason Tackaberry wrote: On Wed, 2008-08-06 at 23:41 +0200, Dirk Meyer wrote: I will try to replace the imlib2 code with pixbuf and we will see. But it is late now, I will do this tomorrow. Don't bother. I ran the test and imlib2 is faster, but only by a slim margin (like 7%). See attached benchmark. pixbuf needs more time to load the images than it could ever safe. But I noticed that some images from the flickr test look wrong when using clutter 0.8. They look ok with 0.6. 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. It's nice to know these sorts of performance characteristics, yeah. So what do you think, will the tv guide be a problem? No, it won't use images and text is faster. Dischi -- A real friend is a friend with chocolate. - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
Dirk Meyer wrote:
I'm in the progress of changing it, it may take a while. ETA:
Friday. The beacon test cases are working now with the new code (not
in svn), but there are some FIXMEs I need to find a way to solve and
the freevo gui testcase is still broken.
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.
Here are the results:
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.
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.
Now we switch into the gobject loop for rendering. Note: the second we
lost above is in the main loop so it does not block animations. It
could also be done in a thread to keep both loops alive.
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:
| clutterobj.set_from_rgb_data(imlib2obj.get_raw_data('RGBA'), True,
| imlib2obj.width, imlib2obj.height, 1, 4, 0)
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.
Dischi
--
There ought to be a better way to start the day than by getting up in
the morning.
-
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=100url=/
___
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
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=100url=/
___
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
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=100url=/
___
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
On Wed, 2008-08-06 at 23:41 +0200, Dirk Meyer wrote:
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_.
At least for the actual UI (menus and such), any such images can be
preloaded, at startup or something, since we'll know what images are in
use based on the theme.
Isn't texture_new_from_pixbuf a clutter 0.6 feature dropped in 0.8?
Oh, indeed it is. I wonder why they did that. I suppose it isn't
strictly needed, but it's a nice convenience.
I will try to replace the imlib2 code with pixbuf and we will see. But
it is late now, I will do this tomorrow.
Don't bother. I ran the test and imlib2 is faster, but only by a slim
margin (like 7%). See attached benchmark.
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.
It's nice to know these sorts of performance characteristics, yeah. So
what do you think, will the tv guide be a problem?
import gtk, clutter
import kaa, kaa.imlib2
import time, os, glob
files = glob.glob(os.path.expanduser('~/.thumbnails/large/*'))[:500]
print 'Warming cache ...'
[ file(f).read() for f in files ]
t0 = time.time()
for f in files:
tex = clutter.Texture()
img = kaa.imlib2.open(f)
tex.set_from_rgb_data(img.get_raw_data(), True, img.width, img.height,
1, 4, clutter.TEXTURE_RGB_FLAG_BGR)
dur = time.time() - t0
print imlib2 method took %f (%f each) % (dur, dur / len(files))
t0 = time.time()
for f in files:
tex = clutter.Texture()
pb = gtk.gdk.pixbuf_new_from_file(f)
tex.set_from_rgb_data(pb.get_pixels(), True, pb.get_width(), pb.get_height(), 1, 4, 0)
dur = time.time() - t0
print gdkpixbuf method took %f (%f each) % (dur, dur / len(files))
-
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=100url=/___
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal
Jason Tackaberry wrote: On Mon, 2008-08-04 at 18:24 +0200, Dirk Meyer wrote: So I propose that a kaa.candy.Widget HAS a clutter.Actor. I see the following advantages: - Thread-safe because we do not modify a real clutter actor. One single now_render function could be created to calculate stuff and create the actors in the gobject mainloop - Hide clutter API the user should no use - Support layout Yes, and this is basically how kaa.canvas worked [...] I'm a bit surprised you didn't do it this way to begin with. I should have been paying attention to the candy check-ins, I would have said something. :) It looked like a good idea at that time. I re-used many clutter functions. On the downside a added the strange template stuff no one except me will ever understand ;) I'm in the progress of changing it, it may take a while. ETA: Friday. The beacon test cases are working now with the new code (not in svn), but there are some FIXMEs I need to find a way to solve and the freevo gui testcase is still broken. Dischi -- I say no to drugs, They just don't listen... - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] kaa.candy changes proposal (was: Kaa r3378 - in trunk/candy: . src/libcandy src/widgets)
On Mon, 2008-08-04 at 18:24 +0200, Dirk Meyer wrote: So I propose that a kaa.candy.Widget HAS a clutter.Actor. I see the following advantages: - Thread-safe because we do not modify a real clutter actor. One single now_render function could be created to calculate stuff and create the actors in the gobject mainloop - Hide clutter API the user should no use - Support layout Yes, and this is basically how kaa.canvas worked. In fact, the actual underlying evas object creation was deferred, as was applying properties to the object. For evas, the deferring was done because you couldn't create evas objects without immediately tying them to a canvas, which worked against our earlier requirement of being able to move objects between canvases. You could do something similar here with candy, further abstracting and deferring object creation, which will let you more conveniently take care of all that in the clutter thread. I'm a bit surprised you didn't do it this way to begin with. I should have been paying attention to the candy check-ins, I would have said something. :) I have no idea what the code does. It was copied from tidy. Maybe tidy is already updated to 0.8 I found that code in toys/ but I didn't check tidy. It would be nice if that was updated to 0.8. My changes work fine for non-tiled textures, and it sounds like tiled textures didn't work right even with 0.6. -import clutter.cluttercairo +try: +import cluttercairo +except ImportError: +# 0.6 +import clutter.cluttercairo as cluttercairo There is clutter.__version__ Not really needed I think. Eventually we'll just remove that code anyway, once 0.6 is old enough. - 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=100url=/ ___ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
