Re: [E-devel] Discussion about Evas perfs for scrolling

[Gustavo S. B. <bar...@gm...>]

Sorry, the mail got out of list, my fault :-/


On 11/4/07, Simon TRENY <sim...@fr...> wrote:
> On Sat, 3 Nov 2007 22:36:49 -0300,
> "Gustavo Sverzut Barbieri" <bar...@gm...> wrote :
>
> > On 11/3/07, Simon TRENY <sim...@fr...> 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 systems. But anyway, that would be
> great things to have too (especially to do some reflection effects)! :)
>
> >
> > > 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.
> >
> > AFAIR evas already have some basic check for motion, but it does
> > nothing with that. Since you're just able to do this over Rectangle
> > with A=255, you can check if the objects below the moved objects are a
> > plain opaque rectangle, in this case you'd get your cached buffer and
> > repaint somewhere else... but again, it's more memory and the required
> > opreations (rectangle fill + regular non-styled text) are not that
> > expensive.
> I agree, I don't thing motion-detection is a good solution, as it would
> rarely be applicable and would require an expensive algorithm (and
> more memory indeed!). But again, the viewport-based solution does not
> use motion-detection, so it's still fine :)
>
> >
> > > 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! :)
> >
> > I think this specific case doesn't worth the pain. Maybe it's more
> > interesting to have someone implement this expensive-operations-cache
> > solution (helps scaled images, text styles, gradients)... after it's
> > done, we could also try to have per-region caches... raster also have
> > some ideas about this, keeping some tiles of the screen and reusing...
> > but I found it more difficult to implement.
> The viewport-based solution would be a generic solution, not something
> case-specific. It would not require a plain ackground with no overlay,
> with no drop-shadow... It would really work in all cases (but would
> require a second Evas).
>
> Regards,
> Simon TRENY <MoOm>
>
> PS. You sent this email to me only. I don't know if you intended to
> send it to the DevML too, so I've replied to you only :)
>


-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: bar...@gm...
   MSN: bar...@gm...
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010