Hi Yale,

thanks for continuing to investigate this! Some comments:

Am 09.02.2018 um 16:02 schrieb Yale Zhang:

I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change

3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92. This reduces latency by ~10ms (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.

https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what

While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/

But there is still way more speedup to be had:

1. rendering cache slows things down 6x! Compare cells E9 & E10 in the spreadsheet.

WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea

2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23

I made 2 changes:

a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

b. replace surface_content = gdk_window_get_content (window); in gdk_window_begin_paint_internal()

with surface_content = CAIRO_CONTENT_COLOR_ALPHA

why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?

3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?

-Yale

Regards,
Eduard