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 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
