Re: scrolling performance

[Damon Chaplin <damonachaplin gmail com>]

On Wed, 2013-12-04 at 15:54 +0900, D M German wrote:
> Hi Damon, everybody else,
>
> I have a question about how scrolling performance.
>
> I have been doing some testing scrolling seems to be an expensive
> operation.
>
> Let me explain:
>
> we try to be efficient at scrolling. We have a background process that
> processes the requests for scrolling. This way we can throw away
> requests that come faster than we can process them. 
>
> But it seems that in goocanvas the scrolling speed degrades very 
> quickly depending on how many items are in the canvas. With one: a big
> pixmap, it works relatively well. 
>
> With few annotations, the performance is visibly degraded, and scrolling
> is no longer responsive.
>
> I have made sure that "redraw-when-scrolled" is FALSE.

Unfortunately GTK+ always redraws the entire window when it is scrolled
now. I'm not sure when that changed, possibly since GTK+ 3.0. This could
be having a very bad affect on performance.

GTK+ uses GtkPixelCache internally to speed up scrolling now, but I
don't think that is exposed in the public API.


> is there anything else you recommend we can do to improve performance?

Changing the cairo options seems to affect the drawing speed a bit, e.g.
using CAIRO_LINE_CAP_BUTT and CAIRO_LINE_JOIN_BEVEL may be faster. 

Setting "antialias" to CAIRO_ANTIALIAS_NONE is faster too, but doesn't
look as good.


It might be an idea to run it under valgrind to see where the
bottlenecks are. I may try that later.

Damon