On Tue, Nov 11, 2008 at 12:49 PM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > On Tue, 2008-11-11 at 10:25 -0400, Ian Lawrence wrote: > >> > What sort of specific resources are we talking here ? >> would be a GPU :-0 >> >> Others are looking at performance issues too >> http://lists.o-hand.com/clutter/1209.html >> and it seems loading images into GL textures is an expensive process >> which can only realistically be achieved with extra hardware and/or >> some future caching system . This cost needs to be taken into >> consideration when other solutions like EFL already exist and have >> been proven to work well in this space. > > you have taken that email completely out of context. > > pushing textures on the GL pipeline is an expensive operation which > entirely depends on the memory and bandwidth available; aside from some > state caching and avoiding known slow operations (like uploading a > texture in the middle of a paint sequence, especially on GLES hardware), > there isn't much anyone can do since it's a hardware issue. > > software rendering is plagued by the same issue, with one important > difference: if you use the GPU you won't be blocking the CPU as well - > software rendering cannot do that; not only it cannot do that, it will > also be susceptible of processes blocking the CPU. and at the end of the > day it will still require to upload data to the GPU in order to display > it on the screen.
Yes, let's make it clear for outside graphics guys that I guess includes Ian: hardware helps, it always do. If you cannot upload to video, it's a problem with software as well, just see Maemo devices and OpenMoko. > GPUs are here to stay. I have no doubt on that. But unfortunately I don't just do Intel based products, actually yet nobody does it (as there is nothing selling, and the closest open source friendly hardware is beagle and openpandora). But I guess simple ignore the fact is bad, my macbook with supposedly shiny Intel 965M does horrible with GL and even EXA is not working properly, so all I have to do to get nice effects on this 1 year old machine is software. It's not my will, be sure of that as I'd use evas GL engine to speed up my software. And I keep hearing that "OpenGL is here" since Vodoo days, like 10 years ago. [...] > +++ > > we've been kind of sidetracked along the deficiencies of EFL, or its > supposed benefits. the main reason why EFL is not a good candidate for > moblin is that it's completely alien to the technologies that compose > the moblin platform itself. it brings along its own dependencies and > nothing else uses them. Clutter, on the other hand, is tightly > integrated with the rest of the GNOME Mobile platform. > > EFL and the whole enlightenment framework has a poorly-defined roadmap, > it's known to be late in deliverables, it's poorly known as a framework > in the community, it tends to reinvent technologies just for the sake of > it, it does not integrate with anything else that has been defined as a > required technology for moblin, and in any way possible is not able to > deliver, or be a part of, an interesting and successful platform. I have to agree with the "poorly-defined roadmap", but that invalidates the "late in deliverables" since no deliverable was ever specified due lack of roadmap. That's a problem we're trying to solve, I hope first semester next year we get it 1.0 and then go with Mark's 3/6 month release cycle. As for reinventing libraries, it's not true. Except by ETK, which I avoid completely, E components are there to fit their use cases. Evas had (and still don't have) any comparable counterpart. Ecore could be confused with GLib, but many data structures are implemented differently (now moving to Eina) and we try to keep common cases fast, we have append O(1) and count O(1) lists, easy to use (and actually used) stringshare (equivalent to g string chunk) and so on. Main loop supports more primitives than GMainLoop (however is not thread safe), so you get it, there's lot of different stuff). I also see no Edje counterpart (but I'd really love too, Qt guys have QEdje and it's wonderful). Now about clutter being more well integrated, that's very true of course. But integrating EFL and Gnome is just a matter of main loops. So far we had no such requirement to do main loop integration and I fear GNOME would not accept new primitives (I already talked to some guys at conferences) and I will postpone that as much as possible. For GStreamer we use a pipe to communicate them, other libraries as librsvg, libxml2, dbus, hal, inotify and others can be used as is (there are code in SVN using them all). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 _______________________________________________ Moblin dev Mailing List [email protected] To manage or unsubscribe from this mailing list visit: https://lists.moblin.org/mailman/listinfo/dev or your user account on http://moblin.org once logged in. For more information on the Moblin Developer Mailing lists visit: http://moblin.org/community/mailing-lists
