Krita has this setting, and I think it might help a lot for performance with large brushes or lots of dabs-per-xxx. Am I correct in my assumption that every call to stroke_to invokes a screen update? That is, every single dab is its own screen refresh?
If so I think some of my insane-o brushes that create bazillions of tiny dabs would see a huge performance benefit even limiting FPS to 60. On slower systems limiting to 30 or 10 might even useful.
I suppose the tile storage could get out-of-sync with what is on the screen, which might be really hard to reconcile without triggering a full screen refresh every once in a while. Or maybe the in-between frames just update a semi-persistent pending_dabs bounding box in a way that only grows the bounding box bigger and bigger. When we finally refresh the screen we can combine the current dab’s bounding box w/ the pending_dabs bounding box and and do the refresh. Then reset the pending_dabs bounding box and repeat.
This is appears to be an incorrect assumption, so maybe this whole idea is not relevant. I added a print time statement to the tile rendering function and it really is not called that often. The framerate I think is the rate that your input device registers new coordinates. If I really went wild I was able to register up to 60 tile draws per second, maybe it could theoretically be useful to limit this. However, that is definitely not the bottleneck compared to trying to render those dabs.
Gotta remember that Krita is using OpenGL to render the canvas which is one of the reasons why they can achieve smooth rendering of large brushes. I think the appropriate way to handle this is improve OpenMP support. I heard last time you said that MyPaint really isn’t taking advantage of all the cores in a CPU?
Yeah, I filed this bug if you want to verify it OpenMP not enabled w/ --enable-openmp, needs CFLAGS · Issue #116 · mypaint/libmypaint · GitHub
It will use pretty much all the cores if you mange to get openMP configured and use a really big brush. I think the code only activates openMP when there are >3 tiles to render or something like that, likely because of the extra overhead of using openMP.
I really wish we could use OpenGL, but the cairo GL backend is not even enabled on so many distros, and pycairo doesn’t even have bindings for it anyway. Maybe there is some way to bypass cairo entirely for the main canvas and use pyglet or something. If we used OpenGL I think we could get GPU based color management (and more) via OpenColorIO w/o much overhead.
