New build available:
- Don’t render canvas cursor when using selection tool
- Fix canvas cursor not updating visually according to the new brush setting.
New build available:
You’ve recently mentioned a few fixes related with copying/pasting and the selection tool. I figured I should mention some of the issues I have encountered with the selection tool of the MyPaint version, just in case.
I like using the gray background and when I select an image and move it to a different location on the same frame I get a white square box in the original location. But it disappears when I hit enter.
When I rotate the image, the image changes size (gets smaller) as I rotate, but fortunately it goes back to the original size when I hit enter.
When I begin to draw again on the same frame, the drawing that I moved and rotated earlier gets duplicated.
Set background to grey. Draw something. Select drawing. Rotate drawing and move drawing to a different location on the same frame. Draw something else on the same frame.
Thanks for reporting
Confirmed on linux. 1 and 2 are now resolved. Thanks!
Before I forget, I recently and accidentally closed the brush selector window (where the MyPaint Brushes are) and realized that there is no easy way to get this window back without restarting or clicking on the reset windows button. At least none that I know of.
Ah… yes you’re right, I forgot to add it to the menu. it has been fixed now.
Check if you can do something about the pressure @CandyFace
The 3. bug should be fixed now too. After I fixed it though, it let to another bug… The first is as you describe, it would slightly offset the image, but after that if you successfully moved the image and kept the selection, you could sometimes also make it crash…
While debugging, I got some time rethink how to re-apply the transformed image into the mypaint backend, which should result in a nice performance increase when transforming on a huge surface.
I just tried it out and yes it is working perfectly. I can’t thank you enough and I’m glad to hear about the added performance increase.
What I did to workaround was to change the Windows compatibility mode form Win 10 to Win 7, and it worked again.
That said the last build that was working without this workaround for my system was
pencil2d-win64-2020-04-04.zip as the whole batch between April 13th and may 3rd has the original brush system for some reason, and it starts to lose pressure sensitivity from
I feel that whatever you merged into the MyPaint branch after the April 4th version from master, is the culprit for this behavior in both Pencil2D master and in this branch.
@JoseMoreno I wrote you something on Discord. It has to do with the version of Qt
I have another one for you. I’ve been experiencing a number of issues and sometimes crashes. These starts to occur when I have multiple layers and when copying and pasting drawings. They seem random and difficult to recreate but I think I got one of them.
you should observe the drawings from layer two switching on and off. If you keep playing with the selection tool (ie, clicking random parts of the canvas and maybe even switching frames), the app will probably crash.
After a crash I get the following message in the command prompt:
ASSERT: “!selection.isEmpty()” in file …/…/pencil-implement_mypaint_nobitmapsurface/core_lib/src/graphics/bitmap/bitmapimage.cpp, line 222 Aborted (core dumped)
note: I compile from source on Linux
Being that it’s an assert, you can run the app in release mode and the crash should be gone. asserts are debug only, to let the developer know that something unexpected has happened and thus crashes.
I am currently working on fixing some things regarding the selection tool, so I am aware that it can crash the app occasionally. Hopefully the next release will contain some nice improvements while also some bugfixes.
Your last work from day 3th does not have mypaint brushes. Just to let you know.
it’s been a while since I last posted an update… unfortunately it’s not a particularly big one, as I’ve been working on other things the last few months…
Newest release is now up to date with master and contains a bunch of bugfixes.
These changes are still only related to bitmap, the vector backend is still broken but I’m working on that as my next priority.
Test it out and see how it behaves.
Make sure you grab the latest version ( beware the timestamps! )
This will likely happen from time to time, as it builds to the same folder regardless of the branch i’m working on… I’ll look into making it separate my builds per branch, that should fix the problem.
@CandyFace Awesome, thanks for updating!
Well, I just tested, and I’m afraid I have some feedback :
Basically it seems that as we feared there must be a certain patch or set of patches in the master branch that messes up with the drawing calculations, and whatever patch that was included in the merge you mentioned has affected MyPaint’s brushes stroke interpolation.
In today’s MyPaint version, the line drawing became broken when I drew even remotely fast, and i don’t have pressure sensitivity unless i enable Windows 7 compatibility on the .exe
I recorded a video to showcase this problem, but honestly it is worrying that something outside the library would affect the drawing this much… basically it makes it feel like there’s no improvement in the drawing calculation even though it’s a library specifically designed for that, and it bothers me specially because we know how much you’ve worked on this!
Using the version from April 4th for comparison, while it still has related issues, the difference feels like night and day. The older version is somehow much more smooth and responsive, accepts faster input and doesn’t require me to enable the compatibility with Windows 7
Sorry for bringing these issues so soon, but I think it’s something we can’t allow to pass to the new brush engine no matter what. Please let us know what we can do to help you
Not sure about the compatibility problem that has become a problem for a while now in master but yes it’s an existing problem that comes from an earlier commit and because of the merge with master, it now also affects this branch…
As for performance, it’s not quite measurable because there are lots of debug information which can heavily impact stroke performance, I for example had a message that would fire at each mouse move event, this would definitely have a huge impact on the stroke. The nightly builds are still debug builds so nothing is optimized
Try the latest release from today and tell me if the problem is gone, if not then i’ll look into it.
If you compile the build yourself using release config, then you should see a huge improvement in performance too.
@CandyFace I’m sorry! You’re right I should have tried testing a release build before anything however I just didn’t want to miss the momentum as I had a bit of free time to test.
It didn’t cross my mind it was a debug build and that could affect the performance, but for some reason now I always expect a debug terminal in debug version, guess it’s a side effect of my current job
Anyway, if the performance issue is just a side effect of being debug that’d be nice… but even then I have to logically inquire about it, is it possible that the debug information you have is not that different from what you had during April’s version? I mean I’m assuming April’s version was also a debug build and it probably had similar events firing since you were testing the brushes and drawing feel very thoroughly back then as well.
Either way I’ll test the other version you mentioned and then i’ll compile the branch to test and provide you with more accurate feedback.
Thank you for always being helpful when it comes to these issues! I know everyone really appreciates all the hard work you’ve put in, I’m sure I do!
I usually do not keep debug logs where it hurts performance too much but I did this time around, so it really would make a huge difference.
I tested some of the earliest commits from April 4 and I did not see see any difference in performance, so whenever you have some time, do try to compare the April 4 build against the latest build again