On Sat, 3 Nov 2007 16:35:52 +0100 Simon TRENY <[EMAIL PROTECTED]> babbled:
ok - yes. for evas it has no concept of blitting the canvas contents directly (scrolling). i have known this for a long time - it's the weakest point. now solving this is NOT trivial. my original preferred solution is literally detecting motion vectors (looking at all objects, their properties and looking to see if groups of them move together - if they do, mark a motion vector that the engine, if it is possible, can punt off to the target display system to do a hardware blit as opposed to a re-draw). i have code that does this. you are right. it's expensive. it is not hyper-fast. it is quite possible we will spend more cycles detecting blits than just doing redraws. for large canvases (1600x1200) it still would be a win as the expense of a redraw could be quite nasty. but for smaller ones we almost definitely will lose. i have held off on this basically hoping hardware catches up (doing redraws with 3d chipsets these days is so fast - blitting is almost pointless). so that goes to your other suggestion - viewports. in the very beginning i did intend these for scrolling - but the way things have developed this really didn't pan out. we now put multiple regions within a canvas that could scroll independently - this means we need another solution. so what is that? well there are 2 things we need. 1. a scale cache. this will just make rescaling much cheaper (if its smooth scaling). this requires we have a tiled cache system that can take an input primitive/object/image/whatever and then be able to create output tiles given input properties (eg a scale, rotate, etc. etc.). the tiles will get populated as they are needed and a certain number of tiles will be kept by the system in cache. this means only output regions intersecting tiles get rendered. making a choice to cache a tile or just raw scale and render is where the efficiency is going to get tricky - if we cycle the cache too much it will be a slowdown, not speedup. this can ALSO speed up fancy text rendering BTW. this will make a redraw of a big screen simpler/faster/cheaper. 2. a scheme of doing blit (scroll) detection that is FAST. as above - the scheme of detecting based on ALL objects and their properties just isn't going to work. we need another scheme. we need some form of "collector" object - much like a smart object, but SPECIFICALLY for scrolling/containering. a method to set the child object offset will then allow for detecting blits easily (all objects WITHIN the scroller object just get a blit - IF you are in 32bpp. 16 and 8bpp can't do this if they have dithering though). remember scrolling/blitting can only really be done if the region is solid. the moment it has an alpha channel on top of something underneath, you have no choice but to redraw. these 2 things can be worked on separately though. if we just add the "Scroller" object now and reduce scrolls to redraws - we have the API and etk/ewl will have a chance to move to it and change. it will not be a benefit - UNTIL we add actual blit support. i always wanted this. the problem here is - there are a million things we could do to improve evas. scrolling is definitely important. the real question is - how important? i think the most important bit is a simplification of the engine API - and turran's new eneism work could be part of that. along with work jose has done a lot of before. better vector support would be great. AA polygons are right on the top of my list. fixing bugs in the gradient filling code is important. man - there's SOOOOOOO much. :):) one day we will need to add z axis support - it will make life incredibly complicated (yes 3d. i have kept out of it because to do that and make it fast is NOT easy. we can do so much without it). > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
