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. GPUs are here to stay. > Ever since Emmanuele pointed out the class clutter.Script(GObject) to > me I thought that this could be a good place for function calls like > clutter.Script.compress_objects and clutter.Script.cache_objects ClutterScript has *zero* to do with caching or compressing objects. what would you mean by "compressing" a GObject, by the way, I have absolutely *no* idea. I'm really sorry, but apparently you haven't any knowledge of what Clutter does internally, so you should either read the documentation and the code or refrain from commenting on this to avoid generating further confusion in a thread that's already pretty messy. +++ 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. ciao, Emmanuele. -- Emmanuele Bassi, Intel Open Source Technology Center _______________________________________________ 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
