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, but just the elements
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 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 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/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find
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 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
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
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
[E-devel] Discussion about Evas perfs for scrolling
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
