I just updated to Ubuntu 16.04 and MyPaint became noticeably slower. It’s not quite unusable, but I do have to wait for the stroke now.
The problem goes away if I change to fullscreen mode and hide the UI, but if I do, I can’t see my reference images.
MyPaint 1.2.1-beta.0+gitexport.3fd40c8
Never mind. Deleting settings.json solved the issue.
What was in your old one? How was it different?
I wish I knew. The next time I’ll just move it to another directory rather than deleting it.
From the changes in MyPaint, I’d say it was mostly my panel layouts. The side panels with their contents of colour selector, a couple of brush sets and tool options disappeared after deleting settings.json.
Managed to make it slow again. It seems to be when I have panels on both sides and the Tone brush set in one of them.
The Tone brush set is quite large. Maybe that’s part of the problem.
It may be worth seeing if layout code is being run all the time or something. Try the technique in https://github.com/mypaint/mypaint/blob/master/DEBUGGING.md#profiling while it’s happening, and compare the hot paths in the call graph image to a responsive state.
Ok, I’ll try that later today.
I think I did it correctly… I got some images at least. 
With the Tone brush set:
Without the Tone brushset:
Test was done with MyPaint 1.3.0-alpha+git.26397ce
The code path graph has a bit too much extra hair to be comfortable to read, so I’m sorry I didn’t get round to this earlier. You have to be a bit focussed on just one activity to cut down on the noise, that’s why docs advise binding it to keystrokes 
There seems to be too many calls to pixbuflist’s draw_cb() 
That’s the consistent little hot spot away from the drawing arc. Some layout issue is probably making it redraw too much, and I think that’s a bug proper along the lines of “pixbuflist: redraws too frequently”. Perhaps if a list is too long for its container, redraw ping-ping happens…
It would be useful to know if it spends a lot of time in there when you aren’t drawing, or even moving the mouse, when the sidebars are visible.
I’ll see if I can do that tomorrow.
Thank you and everybody else working on MyPaint!
It’s definitely doing too much redrawing. This is a profiling pass of about 3 seconds, done when the mouse was idle and not drawing. There was a single Favourites group packed in the sidebar which had a single brush in it. The pixbuflist shouldn’t be overloaded at all in this scenario, and there should be no calls to that draw_cb().
If the item is removed from the sidebar - hidden by clicking its X - the excess calls stop. Similarly, if an autohide has hidden the sidebar, the excess calls stop then too.
This also affects the background image preview list, which is also a pixbuflist.
Reported in our tracker:
I see you are charging ahead with this.
Are you still interested in more graphs from me?
I think we’ve got to the essence of this one now. Thanks for investigating the issue and showing us where to look! Next step is to subscribe to the issue tracker entry if you can: we might ask you for confirmation that the bug is gone later
Is it ok if you ask for it here? I positively can’t find a username that isn’t taken unless it’s iusdfsjdfhg, and I wouldn’t remember that.
Sorry, I don’t want to use these forums as a bug tracker.
Finally managed to find a free username. I’m Sluring on GitHub. Subscribed to the issue.
Just to quickly mention that I was wondering what I did wrong for a couple of hours before discovering that the number of opened panels was indeed causing a slowdown in the processing of input events as described here. I would not have known otherwise on this low-end but still responsive device and now is back to a state as efficient as during a first-time run, which is probably why some users don’t directly see the correlation between the two right away. I can finally resume using it thanks to this archived thread.
And you Bleke solved my problem also. Thanks.
