run shape finding algorithm in non UI blocking thread
taknil opened this issue · comments
Hi, it's probably harder to solve. In the mac app I experienced difficulty operating the UI, especially the STOP button since it was busy.
I suppose one need to run the shape finding in a separate thread so that QT itself can handle all the UI elements.
Hi, the algorithm should already run on separate thread(s) and not block the UI. Unfortunately I don't have a Mac to test with myself to check the problem!
Is it possible that the problem is that the number of threads the algorithm uses by default slows your PC down? Does it help if you set "Max Threads" to something small like 1 or 2 via preferences? It's below the "Random Seed" panel on the right on this screen: https://www.geometrize.co.uk/assets/images/windows/geometrize_image_task.png
I have the same problem. Even with one thread, the more shapes are added the less responsive the UI becomes (which is strange in itself, as I'd expect the result is accumulated as a bitmap or a list of shapes and adding a new shape is constant time…). In fact, above about a thousand shapes I more or less have to kill it.
@cdlm Since your problem gets worse when more shapes are added I suspect that's something to do with the SVG-based view, as I noticed some slowdown with that on Windows. IIRC because I rebuild the whole thing every time a shape is added, because I couldn't see an easy way to append single shapes.
In any case I'll try repro'ing and fixing these issues when I get a chance 👍
I reproduced an issue that looks like this on Windows: when there are thousands of shapes rendered at a high resolution, and new shapes are being added rapidly, the UI thread gets blocked up doing all the SVG drawing.
So, a workaround to try: hide the SVG view when using lots of shapes, use the pixmap one instead, and note difference in responsiveness. Latest builds are here if you want to test: https://github.com/Tw1ddle/geometrize-installer#development-builds
I also fixed a bug where old SVG shapes would linger after the "Clear" button was pressed that was probably causing some slowdown.
I'll look into better ways to render the SVG in future, it doesn't look simple to make it more efficient using the public QtSvg code though.
Closing this, feel free to reopen if I'm wrong about the slowdown being due to the SVG view redrawing causing slowdown.
I'll probably optimize/rate-limit the SVG rendering or add a different default view like an OpenGL-based view instead in future, but the workaround above should do for the time being anyways.