Hi guys! Evas is a really great lib with very good performances to render a lot of objects, but I think it has one major drawback: it is quite slow when we have to scroll contents (iconbox, list-view, text-view, ...). Indeed, for now, in order to implement this scrolling effect, we have to move all the objects contained in the view. This means that the *entire* view has to be redrawn each time the user scrolls, even by a 1-pixel offset. And if this is a fullscreen view on a 1600x1200 screen, it will require a very powerful CPU in order to have a really smooth scrolling, and I don't think this is acceptable.
If we compare the scrolling performances of Evas with the ones of GTK or QT, it's easily noticeable than GTK/QT are *far* more efficient for scrolling! So.. how do they do that? Well, it seems they just don't redraw the entire view, but just the elements that were not previously visible in the view, and that now are visible. Indeed, when scrolling, a big part of the content was already visible and then rendered, and would just require to be translated to the right position. There is indeed no need to redraw the whole view, but just the elements that weren't visible on the previous frame. Now, how can we do this in Evas? I see two solutions here: 1/ We try to detect the areas that can be "just translated" instead of being redrawn. It would imply no change in current applications in order to get benefit of it, but the algorithm behind it is far from being simple, and it may even use more CPU than it would save from avoiding the whole redraw thing. So, I don't think it's the good way to do that. 2/ We could also use the viewport feature of Evas for this. When scrolling, instead of moving the objects, we could simply move the viewport in the opposite direction. For example, if we'd like a long-scrolled iconbox, we would have a huge Evas containing all the icon-objects of the iconbox, but with a small viewport representing the iconbox-view. Now, when scrolling, no need to move all the icon-objects, we would just have to move the viewport. When moving the viewport, we could then translate all the pixels that are common to the two viewport's geometries, and redraw only the areas that were not in the previous viewport-geometry. This can be done really easily Advantages: it should be a lot easier to implement in Evas, and it will probably give better results. Drawbacks: - Apps would need some adaptations in order to get benefit of this and the scrolled-views would have to use their own buffer-engined Evas (which would mean a bigger memory consumption, but the first solution would also increase memory consumption anyway). - Evas and Evas' engines would need to support viewports that are not placed at 0,0, and viewports that can be moved. But I don't think it should be too hard So, what do you think about this? Any other solution in mind? I'll be glad to hear your opinions! :) Cheers, Simon TRENY <MoOm> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
