Thanks for being patient, here’s a new build with some additional changes.
In this build I’ve introduced a new slider that replaces the old slider and value box.
In the past we have had discussions about combining the value box and slider to be able to make the tool options widget smaller. However another reason for making this change was also that on macOS, the slider implementation has been broken for a long time, causing all kinds of graphical glitches.
I intend to try to get this particular change into the main branch too but before I do that, it would be nice to get some feedback.
The new slider comes in two variations:
Left to right:
Middle to left/right
Certain options scale from negative to positive, as such the slider can also now start from the middle.
@GARTHENNIS Hi. This is a standalone version of Pencil2D, which has MyPaint brushes.
You would have to download the files for your particular operating system separately and install / run it normally.
As long as you don’t try to use two version of the program at the exact same time, there won’t be any issue with having different versions of Pencil2D on your computer.
After testing them I’d say Left to Right. That one felt the most intuitive. Thank you for your hard work as always, the sliders seriously feel so slick lol
Hello! I have got Pencil2D running on the Raspberry Pi 5 / 8GB and I compiled your mypaint_integration brach for it, it runs ok but theres something strange, it happens for example when using a deevad brush and picking colors.
If I press my pen tip onto the colorbox and hold it down there and move it around to find the exact color I want then it gets incredible slow to follow my pen movement, it even slows down to the point where Ubuntu asks if I want to close the program or wait. It’s like the polling interval is causing Pencil2D to stall.
I hope it’s not with the way I built it, I followed the instructions for Ubuntu and it worked perfectly and as I said the code I used was from your branch called mypaint_integration.
Well I also built the main Pencil2D master branch but I can’t see any slowdown in the brush or color picking, in fact I notice what a huge difference it is between them.
Even if I go the maximum size of the normal brush (200) it feels snappy and I can pick colors easily.
In the Mypaint version I also noticed that I could get it in the waiting state if I changed the pressure by holding down the pen on the slider and moving it form left to right, it’s like the same sowdown happening there also.
I also tried to get this to happen on Windows but it’s not at all the same problem there, it works perfect there, so a bit strange really. To me the latest MyPaint build for Windows is very very good and feels snappy.
I could try record this, if I get OBS set up on it
Yes it definitely has something to do with disk I/O I had the performance monitor visible while drawing and when ever I got the problem it started to heavily access the disk, it’s a bit strange though because I tried replicate the error a few times after restarting P2DMP because I suspected it had something to do with how big area I painted on but a few times now I haven’t been able to get the same slowness happening even though I had even larges areas I painted on and even 3-4 frames of with large areas that I swapped between and painted on.
I guess I will have to try some more and see if I can see a pattern here what would cause the slowdown.
I believe it has nothing to do with drawing on the canvas as that’s all stored and updated in memory until you save or it automatically saves.
The culprit is more likely to be that we previously wrote to and read tool property changes from disk immediately, which happens a lot more often when using a tablet because of its polling rate.
Hi, I’m new to the forums and I’m very interested in the mypaint version, so I can try to use different brushed to animate. But I can’t download from any of the links? It gives a 404 message. Am I doing something dumb? :T
Ok, first of all thanks for the update, I have built it for Linux/Arm and it feels snappier to select colors now. I ran into the same problem a few times now while doing some thorough testing, the slowness sometimes take longer now to appear (at least I think so) I managed to get an output to the terminal window now when P2DMP stalls and it actually fills the terminal with this error:
Warning: No ‘inputs’ field for setting: pressure_gain_log
So when Ubuntu tells me to Wait or terminate the program then if I wait until these messages stop appearing in the terminal then it’s ok to continue, but once I get this problem it’s there to stay so I will end up in the same waiting loop each time I go choosing a color, or I think it would loop also if I try to change the brush setting on the slider, I can confirm later if it’s another error message then.
Hope this is to some help, I don’t know what to think is my problem just related to the architecture I run it on or what is the matter, but I feel there’s enough grit in this 4-core Rasp.PI to handle Pencil2D it’s just that I run in to this problem for some unknown reason.
EDIT:
Maybe not pay to much attention to the error message, I tried a few times more and most of the time I get no specific output in the terminal while waiting. It could have been a coincidence.
Have you made any brush config modifications, if yes, could you upload the brushes folder?
I think you can find the Pencil2D application data folder in either of these paths:
In there you should have a “brushes” folder where all brush configs are stored. The .conf file holds the hiearchy of what tool can use what. The sub folders next to it contain the brushes for the given presets.
How many settings and input configs have you added?
Does it only happen for the brush tool? if so what happens if you reset tool brush configuration for that tool?
The warning could indicate a bug. I’ll investigate that.
I only use the default brushes that came with the P2DMP Build
I tried to not change any settings or add any more input configs
It happens mostly with the brush, in fact I could not get it to happen with the pen
I also noticed after the Wait message disappeared it always outputs ‘false’ in the terminal windows.
I also found a way to ‘reset’ the slowness, if I get this slowness then the fix for it is to press ‘config’ once so that the config window opens, directly after when I close it then I can select colors as fast as before and no slowness anymore.
EDIT:
I seen one time when ‘false’ did not appear in the terminal, also I seen the message: ‘stopped drawing, too slow’ (also seen : NO BRUSH EXISTS FOR TOOL’
I don’t know how reliable these error messages are because I can imagine a lot of things are going wrong just because of the slowness too.
And now I found a way to produce the slowness, if I pan with the hand tool then it gets slow next time I try to pick a color, if I then press ‘config’ and close window then I’m back to normal.
EDIT 2:
Confirmed it also happens with the pen, I just pan once and it is slow to pick colors, doesn’t lag as bad as the brush for some wierd reason.
Hmm.. the panning causing slowness is quite odd, I can’t say right now what causes that.. it shouldn’t have anything to do with the mypaint implementation, meaning you should see this in our master build as well.
As for the brush configuration I can see that you’ve set the pressure gain higher than the normal, which causes for example the brush radius to increase, something you should be able to see on the preview as well (unless it’s too slow to render that is…)
The “pressure gain” slider in particular is quite “dangerous” as it messes with all other properties utilizing the pressure input mode and so it’s very easy to create a preview where it simply can’t keep up.
Does the slowless disappear if you set it back to 50?
On that note… I might remove the pressure gain property in the next release and see if I can incorporate it more seamlessly as a modifier rather than it’s own thing, or maybe just decrease its multiplication factor.
The trigger was indeed the Hand tool or more specifically, the tool switching logic.
I’ve pushed a fix as well as made some other optimizations regarding the preview window.
Given that you’re building from source yourself, give it a shot and let me know if that fixed the slowdown.
The technical explanation:
When the tool changes, we check whether the brush configurator is relevant or not but in any case we allocate it. Once it’s been allocated, a connection is created between the colorbox widget and the configurator, to update the preview.
Whether the configurator is hidden or not, matters not when it comes to updating the preview. As such every color update you trigger through the wheel, triggers a mypaint surface update to happen, at the polling rate of your tablet.
For now i’ve added a threshold to the preview update logic, so that it doesn’t happen too often.
I’ve also added a check so that it doesn’t happen unless the configurator is shown.
In the future however I want to introduce a proper event propagation system that limits the amount of updates the tablet can cause for things that don’t need it.
