GNOME Bugzilla – Bug 415816
add cover browser
Last modified: 2018-05-24 12:25:44 UTC
Something similar to: http://www.apple.com/itunes/jukebox/coverflow.html Would be especially useful when a keyboard is not available. We might be able to leverage our existing browser.
BTW, when we do this we should make it a proper widget. We'd consider using this for a GDM face browser too...
Maybe the widget should just implement a view of a model. Where we have only one cell but the cell always renders the previous, current, next items in the model using cairo. Maybe we can hook animation into a selection changed signal handler.
What is needed here is OpenGL, not cairo (well cairo could do something fancy too I'm sure, but not with the 3D aspect and speed of coverflow). I already made some me-too experiments around coverflow. The hardest part was to figure out how covers should move. I didn't really came with a simple behavior, but it made me code a little animation framework that may prove useful elsewhere. See some videos here: http://kris.dehais.free.fr/artstreamer/ (out.ogg.4 is the last iteration of the program, the closest from what I believe is the actual behavior of coverflow - had to reverse engineer from the small videos on the web, since I don't have iTunes 7) Also banshee has a plugin that mimicks coverflow: http://fleow.berlios.de/ and it seems convincing. (btw, I looked at the code, and the cover placement and animation portion is really small so I guess I missed something).
Hmm, I'm not convinced that this requires GL. That sets the bar pretty high for a lot of people. Cairo should be pretty capable of this sort of thing.
For example, requiring OpenGL might preclude its use on most small devices and handhelds where it is arguably most useful (when there is no keyboard).
Actually using OpenGL seems obvious to me here, because the goal is to replicate our physic world for cover art navigation, so it is inherently 3D. Cairo could do the job (I guess it can perspective distort images to simulate some 3D view), but I think this would be misusing the library. I'm also concerned about performance (especially if the widget is large or is made fullscreen). I recently did a spectrum analyser plugin based on cairo (bug #327367) and I get about 5-6fps when going fullscreen, and it's only using simple vector graphics, so compositing several art images and animating the scene seems out of reach for cairo at the moment (maybe even with glitz). That said, I think we could perfectly make some sexy cover art navigation entirely based on cairo, if we restrict the graphic load (e.g. only showing previous and next albums, not perspective distort the images, ...). The argument about handheld is also perfectly viable, except that the iPhone is actually running coverflow (which uses OpenGL) as a charm. Even if the hardware of the iPhone does not reflect the majority of handheld devices out there (especially the ones that try to have more than 2 hours of battery life).
So trying to look what was possible with cairo, I found that a cairo matrix can only describe an affine transformation, so you can simulate true 3D with it.
(In reply to comment #7) > So trying to look what was possible with cairo, I found that a cairo matrix can > only describe an affine transformation, so you can simulate true 3D with it. > sorry, read : so you _can't_ simulate true 3D with it.
Created attachment 85267 [details] coverflow like mockup
see: http://kris.dehais.free.fr/artstreamer/artstreamer_cairo.ogg (download and play locally for maximum smoothness) for a video showing an coverflow-like made with goocanvas. Things to note: * it's a bit slow. Definitely less slick than OpenGL. In real it's not much fluider than the video. And I didn't put the gradient background I had in my initial mockup. * cairo's image down_scaling is a bit crappy (afaik the devs know about that). OpenGL gives nearly free mipmap subsampling. * cairo can actually do pretty things!
That looks pretty cool, although it does look a bit slow. Cairo would probably be faster/better if it used glitz, but that backend is still experimental. If we wanted to use OpenGL, I'm not sure whether we should use GtkGlArea, GtkGlExt or something else.
Not surprisingly, KDE people have attempts to clone coverflow too. See this blog: http://zrusin.blogspot.com/2007/03/reflections.html Interestingly, it's done with Arthur, the KDE cairo counterpart, and the author claims 60fps. Also Arthur seems to handle 2D projective transformations.
Your demo looks pretty nice to me. Even at the present speed without any more optimization I think it isn't too bad. Also the pure 2D approach actually looks pretty good too. Might be interesting to use sysprof or similar to see where the slow code paths are and try to eliminate them. I think there is probably a lot of room for performance improvement in cairo too. And the developers seems eager to help in this area. One thing is that we should have a nice API for adding annotations below the images. In the RB case it should say "Artist\nAlbum". In the GDM case it would say "Realname\n(username)" or something. Cool stuff. Where's the code? :)
This could also be implemented as an option for the filebrowser (either disabled by default or as an option in the View Menu. There's now by the way stable compositor for Gnome in trunk : http://blogs.gnome.org/metacity/category/compositing/iains-compositor/
Ehm... I think I should mention that I'm working on this -> https://wiki.ubuntu.com/DesktopTeam/Specs/HardySparkle which is pretty much what this enhancement-bug requests.
Excellent! (I faithfully follow your work, so I knew you would tackle this some time :)) Here are some comments after the spec page: * I think GL_ARB_multitexture is part of GL 1.3 (see http://www.opengl.org/registry/specs/ARB/multitexture.txt) * Could you think of a mode not requiring GLX_EXT_texture_from_pixmap ? (e.g. putting the cover art view and the controls in separate cell of a GtkVBox, and a fullscreen mode as the Totem one) * as you mention I think the play/pause and volume controls are redundant in windowed mode. * The idea of fading to a screensaver after some idle time is cool, but I think it should fade to something cover art related (like random covers flying on the screen) instead of the equalizer thing, that could be provided by another plugin (visualization or dedicated spectrum plugin (see Bug 327367))
Using a library such as Clutter[1] seems to me as a much saner approach than trying to accomplish this with Cairo or OpenGL directly. [1] <http://clutter-project.org/>
This bug and bug #516186 are duplicates, but both have interesting content :-/
Pure cairo could be used but from my experiments smooth animation will have to wait for it to be hardware accelerated.
*** Bug 516186 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/340.