Severe performance regression

[Patrick Storz]

There is a sever performance regression when panning in I Inkscape r14851 64bit on Windows 7 x64.
Performance was fine in Inkscape r14762 64bit.

Steps to reproduce:
- start Inkscape
- make sure the window is sufficiently large (it actually seems the issue is only happening for large window sizes which I don't understand)
- Pan the canvas using Ctrl + Right mouse button

Result:
Performance is really bad, the canvas only moves in a stuttering motion

I assume it is a regression caused by the "sp_canvas" fixes done by Krzysztof Kosiński during the Hackfest.

[Patrick Storz (ede123)]

I just realized the motion of the canvas in not only very unsmooth, also redrawing performance is severely regressed.

Often the canvas does not update during panning at all or is updated only sporadically.

[Patrick Storz (ede123)]

Probably related bug #1571188

[jazzynico (jazzynico)]

Confirmed on Xubuntu 15.10, Inkscape trunk rev. 14855.
Panning if significantly slower than with 0.91.

[jazzynico (jazzynico)]

Well, I'm afraid some other actions are slower. For what I've just tested:
* using a gradient on a simple rectangle (the only object on canvas!).
* moving objects.
* resizing object.

[jazzynico (jazzynico)]

Not reproduced when compiled with the gtk3 option.

[Alexey (allkhor)]

Confirmed on Xubuntu 14.04, current Inkscape trunk.

[Patrick Storz (ede123)]

Is anybody working (or at least planning on working) on this? I sadly don't have nearly enough experience...

For me it's not a medium priority since on my machine it makes Inkscape trunk basically unusable, therefore being more of a blocker right now...

[jazzynico (jazzynico)]

Adding the "blocker" tag. Inkscape is now almost impossible to use with Gtk2, so except if we want to get rid of Gtk2 for 0.92, the bug must be fixed.

[jazzynico (jazzynico)]

From Bug #1577396, using Inkscape with no dialog, control bars, etc. (using Shift+F11) restores expected performances.

[Krzysztof Kosinski (tweenk)]

We decided that the best way forward is to revert the canvas widget changes in the 0.92 branch, and drop GTK2 support in 0.93. It looks like GTK2 and GTK3 are at the very least very hard, if not impossible, to support with a single rendering code path.

[Krzysztof Kosinski (tweenk)]

0.92 branch was created today and the changes were reverted there, please test.

[su_v (suv-lp)]

Quick test with lp:inkscape/0.92.x r15024:
1) Canvas rendering is broken: horizontal stripes which are not redrawn/refreshed correctly - see attached screenshot. Zooming on or out or toggling layer visibility does not help, nor switching to outline view, nor turning off rendering cache (via command line, or prefs).
2) Preview images in file dialogs produce instance crash on dialog open.

Tested and reproduced with GTK+/X11 2.24.29 and GTK+/Quartz 2.24.30 (on OS X 10.7.5).

[su_v (suv-lp)]

Follow-up report filed about the crash with file dialogs:
* Bug #1607698 “Crash on 0.92.x on file open”
  https://bugs.launchpad.net/inkscape/+bug/1607698

[su_v (suv-lp)]

Follow-up report filed about the rendering regression:
* Bug #1608152 “Canvas drawing errors in 0.92.x after r15024”
  https://bugs.launchpad.net/inkscape/+bug/1608152

[jazzynico (jazzynico)]

Another possible regression:
* Bug #1608216 "Crash when resizing the application window (0.92.x)"
  https://bugs.launchpad.net/inkscape/+bug/1608216

[Bryce Harrington (bryce)]

su_v, it appears that thanks to nicu the bugs you list in comments #13, #14, and #15 are now all closed as resolved.

You had mentioned some other issues in comment #12 - could you doublecheck that those are now resolved as well? If not please open new bug reports on them or point me to existing bug reports. Thanks!

[su_v (suv-lp)]

On 2016-08-24 04:35 (+0200), Bryce Harrington wrote:
> You had mentioned some other issues in comment #12 - could you
> doublecheck that those are now resolved as well?

The two issues described in comment #12 are covered by the independently
filed follow-up reports referred to in comments #13 and #14.

[Bryce Harrington (bryce)]

su_v, excellent thanks!

[Patrick Storz (ede123)]

I'm afraid this is also an issue in GTK3 builds.

Performance of trunk is much worse than performance of 0.92.x branch.

Just tested on Windows 10 x64 with
- 64-bit build of trunk r15549 (custom MSYS2 build with gtk3 3.22.8)
- 64-bit build of trunk r15513 (devlibs64 build with gtk3 3.19.6)
vs.
- 64-bit build of 0.92.1 r15371 (stable release)

[su_v (suv-lp)]

@Eduard - given that the focus for the commits wrt this report was on GTK2 and the stable release branch for 0.92 (see comment 10), I would recommend that performance regressions with GTK3-based trunk builds wrt canvas panning better be tracked in a separate new report.