In recent versions of libgnomecanvas (2.26.0 affected; 2.20.0 not affected), the refresh upon adding items to the canvas slows down considerably when the canvas is not scrolled down at all (the top edge of the canvas is visible on-screen). This is because large unnecessary parts of the display get refreshed when the vertical scroll amount is 0 (or less, i.e. canvas is smaller than height of window). Adding an item causes the entire rectangle from the top-left corner of the canvas (or of the group?) to the lower-right corner of the item to be refreshed in that case, while if the vertical scroll is >0 then only a small rectangle bounding the item created is refreshed (as should be the case).

To reproduce the problem: start e.g. xournal (note: if you have trouble drawing, disable Options -> Use XInput), and draw very quickly (any kind of circles, squiggles, whatever) near the lower-right corner of the screen while "top" is running. If the vertical scrollbar is at the very top (or there's no vertical scrollbar), top will show that Xorg uses a very large amount of CPU compared to xournal itself, and the drawing is somewhat jagged. If the view is scrolled down even a little bit, Xorg and xournal use comparable amounts of CPU and the drawing is smoother.

What xournal does when you draw is just add a lot of GnomeCanvasLines to the canvas, all sitting within a GnomeCanvasClipGroup for the page. The bug does not seem to be specific to GnomeCanvasLines, since adding text items also generates the same extra refreshes when the vertical offset is 0.

Running xournal in Xephyr in debug mode (which shows red rectangles for the areas of display being refreshed) suggests that, normally, adding a GnomeCanvasLine only causes the refresh of a small rectangular region that encloses it; while, when the vertical scroll offset is zero, the entire rectangle from the top-left of the page to the lower-right corner of the item being added gets refreshed.

Denis