Re: [E-devel] Discussion about Evas perfs for scrolling
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 SOOO 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,
Re: [E-devel] Discussion about Evas perfs for scrolling
On Mon, 5 Nov 2007 20:21:05 +0100, Cedric BAIL <[EMAIL PROTECTED]> wrote : > On Sunday 04 November 2007 17:00:27 Gustavo Sverzut Barbieri wrote: > > On 11/4/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > > On Sat, 3 Nov 2007 22:36:49 -0300, > > > "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> wrote : > > > > On 11/3/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > > But with the second solution (the viewport one), you actually > > > have two Evas: one Evas for the application itself (including the > > > view-borders, the scrollbars, the view-background), and one Evas > > > for the content of the view. The second Evas is rendering into a > > > buffer (through the buffer engine), and this buffer is then > > > rendered into the first Evas, inside the scrolled-view. This way, > > > the second Evas (the one where you'll just move the viewport in > > > order to perform scrolling) just contains the objects of the > > > view-content, and so, there will never be any problem when > > > "translating the pixels". No broken background. We could even > > > have a semi-transparent overlay over the view, and it would still > > > be possible to do the translation-thing with no artefacts. > > > > > > And this solution should be quite easy to implement in Evas (just > > > need to support viewports that are not located at 0,0). It would > > > increase mem-consumption since you have to render into a buffer, > > > but you still have the choice not to do that for your > > > scrolled-views, so it won't change anything for existing apps. > > Only the second solution seems usefull, but if we create a full size > buffer, we will use much more memory than today. Perhaps it could be > possible to have a small buffer that will be near the viewport size > plus a delta in each direction. When scrolled, only the hidden part > are redraw and some are hidden. If the scrolled part are moved > outside of the delta, we just do a memove of the content and we > update all the needed part. It's a little bit more complex, but it > should require less memory and still provide better performance (A > draw back could be that we will not have linear performance, but > that's already not the case). Yes, my idea was to only have memory for the viewport geometry. No need to allocate memory for the full Evas since it's not entirely visible. The "delta-thing" could be great to improve the case where the user scrolls back-and-forth by small offsets, but it would be harder to implement and would require a second buffer (containing only the pixels visible by the viewport, not the delta-borders). So I'm not sure it's worth it. > > > > > so, it's a "optimization" that will not help that much. We're > > > > doing 800x480 at more than 24fps using an 230Mhz ARM... so I > > > > _really_ disagree it's a problem. > > > > > > Well.. on a 1600x1200 view, you have 5 times more pixels to draw. > > > And scrolling a fullscreen tree containing a lot of objects on > > > this resolution is really laggy-ish on my Athlon 1300MHz. And it > > > would even be worse if the resolution goes higher (which tend to > > > be the case with recent screens). > > With a MIPS at 200Mhz and a screen of 720x576x32, it's really slow > when you are require to move many part of the screen. > > > > > What would help here is a general render-cache, I already > > > > discussed this with raster for styled-text and scaled images. > > > > Basic idea is quite simple: count the number of times you do > > > > certain operation on some object (scale, recolor, text > > > > styles... things that are not "optimimum") and if some flag is > > > > set (cacheable==1) you would create a new buffer and cache this > > > > effect, next time you just use it. If you run out of cache > > > > space, it would be deleted and no problem. This would help to > > > > save lots of expensive operations, but it's quite boring to > > > > implement and test. So I'll avoid it until I really need... :-) > > > > > > Yes, it might be useful indeed! :) > > Regarding the cache mecanism, I really agree that we need to improve > it. It should not be to difficult to add scale image to the cache (I > already have some idea regarding this). The others (recolor, > styled-text) are not yet part of the cache mecanism, and will require > more work. But I don't see where you want to put this cacheable flag > and when/how you want to set it. You could perhpas describe how you > see this new cache function (including recolor and styled-text). > > Cedric > > > - > 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/l
Re: [E-devel] Discussion about Evas perfs for scrolling
On Nov 5, 2007 4:21 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > But I don't see where you want to put this cacheable flag and > when/how you > want to set it. You could perhpas describe how you see this new cache > function (including recolor and styled-text). This would be an object property, just like anti_alias. Core would check if this variable is: 1- forced-no cache (what we have today) 2- forced-cache: don't even check, cache it at the first time 3- auto: increment a counter on every blit based on the same properties, if it's bigger than a threshold, cache it. If any other blit is done, zero this counter. 1 is already done, 2 is quite easy, 3 is bit harder/tricky. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - 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
Re: [E-devel] Discussion about Evas perfs for scrolling
On Sunday 04 November 2007 17:00:27 Gustavo Sverzut Barbieri wrote: > On 11/4/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > On Sat, 3 Nov 2007 22:36:49 -0300, > > "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> wrote : > > > On 11/3/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > But with the second solution (the viewport one), you actually have two > > Evas: one Evas for the application itself (including the view-borders, > > the scrollbars, the view-background), and one Evas for the content of > > the view. The second Evas is rendering into a buffer (through the buffer > > engine), and this buffer is then rendered into the first Evas, inside > > the scrolled-view. This way, the second Evas (the one where you'll just > > move the viewport in order to perform scrolling) just contains the > > objects of the view-content, and so, there will never be any problem > > when "translating the pixels". No broken background. We could even have > > a semi-transparent overlay over the view, and it would still be > > possible to do the translation-thing with no artefacts. > > > > And this solution should be quite easy to implement in Evas (just need > > to support viewports that are not located at 0,0). It would increase > > mem-consumption since you have to render into a buffer, but you still > > have the choice not to do that for your scrolled-views, so it won't > > change anything for existing apps. Only the second solution seems usefull, but if we create a full size buffer, we will use much more memory than today. Perhaps it could be possible to have a small buffer that will be near the viewport size plus a delta in each direction. When scrolled, only the hidden part are redraw and some are hidden. If the scrolled part are moved outside of the delta, we just do a memove of the content and we update all the needed part. It's a little bit more complex, but it should require less memory and still provide better performance (A draw back could be that we will not have linear performance, but that's already not the case). > > > so, it's a "optimization" that will not help that much. We're doing > > > 800x480 at more than 24fps using an 230Mhz ARM... so I _really_ > > > disagree it's a problem. > > > > Well.. on a 1600x1200 view, you have 5 times more pixels to draw. And > > scrolling a fullscreen tree containing a lot of objects on this > > resolution is really laggy-ish on my Athlon 1300MHz. And it would even > > be worse if the resolution goes higher (which tend to be the case with > > recent screens). With a MIPS at 200Mhz and a screen of 720x576x32, it's really slow when you are require to move many part of the screen. > > > What would help here is a general render-cache, I already discussed > > > this with raster for styled-text and scaled images. Basic idea is > > > quite simple: count the number of times you do certain operation on > > > some object (scale, recolor, text styles... things that are not > > > "optimimum") and if some flag is set (cacheable==1) you would create a > > > new buffer and cache this effect, next time you just use it. If you > > > run out of cache space, it would be deleted and no problem. > > >This would help to save lots of expensive operations, but it's > > > quite boring to implement and test. So I'll avoid it until I really > > > need... :-) > > > > Yes, it might be useful indeed! :) Regarding the cache mecanism, I really agree that we need to improve it. It should not be to difficult to add scale image to the cache (I already have some idea regarding this). The others (recolor, styled-text) are not yet part of the cache mecanism, and will require more work. But I don't see where you want to put this cacheable flag and when/how you want to set it. You could perhpas describe how you see this new cache function (including recolor and styled-text). Cedric - 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
Re: [E-devel] Discussion about Evas perfs for scrolling
On 11/4/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Sun, 4 Nov 2007, Gustavo Sverzut Barbieri wrote: > > >>>Quite frankly, performance is not a problem even for us running on > >>> ARM machines with 230mhz, that's without any optimization (mmx, sse) > >>> at all. And we're using Python code on top of that! What we miss most > >>> is lack of filter objects (apply blur, rotation, ...), basics of > >>> vector graphics (maybe cairo integration) and 3d as a first-class > >>> citzen. > >> Filters and 3D would be great, but I'm not sure they would be really > >> fast on not hardware-accelerated systems. But anyway, that would be > >> great things to have too (especially to do some reflection effects)! :) > > once enesim (Jorge's baby) is integrated into evas, that kind of filter > can easily be integrated in its pipeline. > > As an example, he has written a small test of enesim that can render an > svg image to a png, and he is written an svg renderer with enesim. In > other words, doing vector graphics with enesim is not difficult. > > I've written (slow) "filters" like blur or bump mapping for evas, but I > think that Jose has a lot of optimized functions for that kind of filter. Actually, enesim will help, but not really the solution. We'll need help from other bits, like support in Evas core as well. Anyway, enesim is a good thing to have, it will sure help to have pluggable evas objects, etc. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - 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
Re: [E-devel] Discussion about Evas perfs for scrolling
On Sun, 4 Nov 2007, Gustavo Sverzut Barbieri wrote: >>>Quite frankly, performance is not a problem even for us running on >>> ARM machines with 230mhz, that's without any optimization (mmx, sse) >>> at all. And we're using Python code on top of that! What we miss most >>> is lack of filter objects (apply blur, rotation, ...), basics of >>> vector graphics (maybe cairo integration) and 3d as a first-class >>> citzen. >> Filters and 3D would be great, but I'm not sure they would be really >> fast on not hardware-accelerated systems. But anyway, that would be >> great things to have too (especially to do some reflection effects)! :) once enesim (Jorge's baby) is integrated into evas, that kind of filter can easily be integrated in its pipeline. As an example, he has written a small test of enesim that can render an svg image to a png, and he is written an svg renderer with enesim. In other words, doing vector graphics with enesim is not difficult. I've written (slow) "filters" like blur or bump mapping for evas, but I think that Jose has a lot of optimized functions for that kind of filter. Vincent - 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
Re: [E-devel] Discussion about Evas perfs for scrolling
Sorry, the mail got out of list, my fault :-/ On 11/4/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > On Sat, 3 Nov 2007 22:36:49 -0300, > "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> wrote : > > > On 11/3/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > > 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. > > > > > > Well, this is possible if you use another X window, it makes these > > things easier... but anyway, you're trading CPU per memory: you'd have > > to keep the list region alive in memory... and do something to know > > it's a list, evas have no concept of list. > > > > > > Also, remember that this is just applicable to constant backgrounds, > > things like one-color (white?), these things are really going away > > with newer themes... and for systems like our (Canola), it's > > useless... :-/ > > Well, you're right, it would be useless with the motion-detection > solution (first solution) since, if you have a fixed non-uniform > background, we could not simply "translate the pixels", or the > background would look "broken" otherwise. That's why the first solution > is not a good one (expensive and case-specific). > > But with the second solution (the viewport one), you actually have two > Evas: one Evas for the application itself (including the view-borders, > the scrollbars, the view-background), and one Evas for the content of > the view. The second Evas is rendering into a buffer (through the buffer > engine), and this buffer is then rendered into the first Evas, inside > the scrolled-view. This way, the second Evas (the one where you'll just > move the viewport in order to perform scrolling) just contains the > objects of the view-content, and so, there will never be any problem > when "translating the pixels". No broken background. We could even have > a semi-transparent overlay over the view, and it would still be > possible to do the translation-thing with no artefacts. > > And this solution should be quite easy to implement in Evas (just need > to support viewports that are not located at 0,0). It would increase > mem-consumption since you have to render into a buffer, but you still > have the choice not to do that for your scrolled-views, so it won't > change anything for existing apps. > > > > > so, it's a "optimization" that will not help that much. We're doing > > 800x480 at more than 24fps using an 230Mhz ARM... so I _really_ > > disagree it's a problem. > Well.. on a 1600x1200 view, you have 5 times more pixels to draw. And > scrolling a fullscreen tree containing a lot of objects on this > resolution is really laggy-ish on my Athlon 1300MHz. And it would even > be worse if the resolution goes higher (which tend to be the case with > recent screens). > > > > > What would help here is a general render-cache, I already discussed > > this with raster for styled-text and scaled images. Basic idea is > > quite simple: count the number of times you do certain operation on > > some object (scale, recolor, text styles... things that are not > > "optimimum") and if some flag is set (cacheable==1) you would create a > > new buffer and cache this effect, next time you just use it. If you > > run out of cache space, it would be deleted and no problem. > >This would help to save lots of expensive operations, but it's > > quite boring to implement and test. So I'll avoid it until I really > > need... :-) > Yes, it might be useful indeed! :) > > >Quite frankly, performance is not a problem even for us running on > > ARM machines with 230mhz, that's without any optimization (mmx, sse) > > at all. And we're using Python code on top of that! What we miss most > > is lack of filter objects (apply blur, rotation, ...), basics
