Am 12.02.2018 um 13:12 schrieb Yale Zhang:
Eduard, please pull change #2 (fix priority inversion) before the immediate rendering changes. Without it, the lack of status bar & ruler updates are expected.
I think we're running in circles here... Most of my comments (as well as yours regarding direct drawing) referred to #3. The only issue I had with #2 was that Rulers seem still to be updated with a high priority and prevented the canvas to redraw (in stock MSYS2 builds and therefore with CSD=0).
Yes, I am using CSD=1 in my testing (for both optimized & original GTK). But CSD isn't the actual reason for performance difference. It's because of the rendering code path CSD=1 uses (draw to CPU memory buffer, then send to UpdateLayeredWindow()), vs CSD=0 (draw directly to GDI device context - surprisingly this is slower until my optimizations).
Please note that CSD=0/1 in our stock MSYS2 builds makes a *huge* difference. If that is really not the case for your custom builds we might want to start looking into that, too. Maybe we're facing at a more fundamental difference. As MSYS2 is the official way to get GTK+ for Windows nowadays such a difference might be very relevant for many projects.
Are your cross-compiled libraries using mingw-w64? Which OS are you using btw? (I'm usually testing on Windows 10 - I'd not be surprised if there's some major difference compared to e.g. Windows 7 wrt to the low level drawing functions).
I'm very interested in testing your GDK-modifications and see how they behave with the MSYS2 builds, so if you could drop a patch somewhere that would be much appreciated!
I did get an error from the CI build after the multithreaded rendering feature. It doesn't even get past CMake configure stage, so not very useful. That's because the build server doesn't have the Boost libs (which I use, not just the headers).
I think you looked at the Linux build - Windows CI is "external" via AppVeyor and has the required Boost libraries. It's just not working in your branch right now because an upstream update broke updating but I pushed a workaround for this already in the master branch [1] (that's why I suggested to rebase)
[1] https://gitlab.com/inkscape/inkscape/commit/85d7fa343f477d8faae6cbde90ae7a24... (I messed up the rebase so it's authored by Tav, sorry for that)
On Mon, Feb 12, 2018 at 2:41 AM, Eduard Braun <eduard.braun2@...173... mailto:eduard.braun2@...173...> wrote:
Am 12.02.2018 um 10:15 schrieb Yale Zhang:"As noted before, when rulers are shown there still is no redraw with this change" It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?They are usually the latest available (think of MSYS2's MINGW-packages as arch Linux for Windows), right now gtk 3.22.26 and glib 2.54.3. Aside from disabling CSD they are unpatched. Just to make sure we're not comparing apples and oranges: Are you using CSD in your builds or not? This switch made a huge difference before, so if you're working with CSD enabled this might be the likely explanation why some things work in your builds that do not work in the stock builds."It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI" You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build. https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC <https://1drv.ms/u/s%21AngRQgSreBCehy4R7D3x3Y2vIXPC>I used https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9 <https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9> as the later commits did not compile for me. I'll check your build this evening. We also have CI builds with MSYS2 available: https://ci.appveyor.com/project/inkscape/inkscape/history <https://ci.appveyor.com/project/inkscape/inkscape/history> If you rebase your branch on master your branch will be built, too (as long as there are not more errors/warnings preventing the build)I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.I'm just saying that priorities have been tweaked before to make all UI update properly and we should aim to retain this state. If direct drawing is compatible with this goal (I guess it was in gtk2) that's probably fine."Have you published [GTK3] code anywhere? " No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.It's like SMS... it just works (even today)... A lot easier than all the modern stuff that claims to be easier than IRC. I've talked to gtk devs on IRC before and it's the easiest way to get some interaction (bug reports usually fall into oblivion sooner rather than later).BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()). "Is [render cache] always slow?" It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.I see... I guess before the low complexity scenes were not that important as redraw times were sufficiently fast anyway. User reports of slow redrawing usually involve blurs (or less frequently other filters).For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable. I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.I'll try to build this evening. As recommended before you could check the CI to make sure your branch is properly built, which should help with testing. Regards, EduardOn Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote: 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 change3. draw immediately (78d47938) this partially revertsKrzysztof'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 <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 <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?-YaleRegards, Eduard