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.
Simplified changelog:
Quick sizing works now and shows correct size.
Only changing width is possible… this is intentional currently. Feather is not as simple as it once was, so I’m not sure that one is coming back but it could be tied to another brush property.
Improved performance when transforming huge chunks of an image.
Fix Polyline would render below previous stroke while drawing but would be be shown correctly after the action had been completed.
Various performance optimization regarding rendering bitmap tiles.
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.
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.
@MrStevns 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
I’m very happy of this mix, as an early MyPaint adopter. Thank you for this great work :).
I managed to compile it on Arch Linux, and made an AUR package, called pencil2d-mypaint-git, to allow other user to take benefits of it too, testing it and perhaps add some returns on problems.
It works really fine, there is only a bug, brushes disappear often, need to restart Pencil2D to see them again. (Edit: I understood, other tool was selected, I don’t know how)
I Noticed today, that when I try to delete vector layer, the bitmap drawing is strangly moved bottom left, and reduced.
From a new project (from scratch), this can be viewed by, just after removing the vector layer, drawing at upper left top. the drawing will appear at bottom right.
Another problem. When draws are done on several bitmap layers, during play, the layer below the current selected one display only keyframes at keyframe time and no frame between them.
Thank you very much for you work, It works perfectly :).
At the same time I discovered 2 bugs in my Arch Packaging file with this update.
The package version is based on master branch git version, need to be relative to the implement_mypaint_nobitmapsurface branch.
The src directory need to be cleaned at each compilation
I updated the packagebuild recipe:
Now the method to access to branch follow arch PKGBUILD rules (first time I do this), and this resolve the number versioning.
I added the make clear at this time, not sure it is very useful after the fix with branch usage, but as compiling time is not very long, it is more secure for now.
Noticed bugs that are specific to the MyPaint branch:
The colopicker tool doesn’t work at all.
draw a curve on a frame, move the red cursor to another one, draw few curves (a new frame is created), move another time the red cursor create a third frame by few drawings (2 or 3), then use ctrl-z to remove all the drawings, when added draws on the last frame are removed, the frame will become a copy of the previous one.
Sometime CTRL-Z (to cancel) doesn’t work at all, I for this time didn’t find any easy method to reproduce it, that’s perhaps a bug in the main branch, I believe I had this too, If I found a reproducible way I will add it here.
In a few rare time, after cleaning a frame (box + ctrl-x), drawing again in this frame, will show again the previous delete image, by rectangles parts, following the current drawing (probably due to memory allocation algorithm for new drawings ?). If I catch again the cases, I will make a screencast. I tried to save a project and open it again, to send you an example, but after restarting, the bug is no more here.
Too nice, you are very fast at fixing bugs :). thank you very much.
Not as a bug, but perhaps something to thing a little more about behavior, and what is best or not for user. That’s some changes related to my test on this branch since few days: When I continue to ctrl-z, it continue to cancel drawing on previous picture, I don’t know if that’s better (seems more logical after all) or less good, and at the same time the new frame are not deleted (should they be?).
I will try to make a little scene this evening, to see how it behaves now.
Ideally the frames should be undone ie. removed again. I’ve already implemented those things in another PR https://github.com/pencil2d/pencil/pull/953 it hasn’t been merged yet though.
I spent lot of time trying to draw a background, so no time for animation, I discovered a little more how to use brushes between pencil/fountain pen/brush ones. I was working on a FullHD picture 1920×1080. I noticed that ctrl-H doesn’t display the whole camera view. but instead a part of the picture is displayed, I don’t know what zoom is used.
To better understand, the picture have two red frames here, beginning from middle:
1 for the viewport view (ctrl-H= reset zoom/rotation)
2 Aproximately the whole screen so between red frame, the part hiden by GUI.
The light gray part is, after unzoom the camera view.
When I export 1 frame as image, i have the 1920×1080 picture, with the camera view ( the size set in software is also confirmed by double-clicking on Camera layer button).
I tried to reopen it in MyPaint 0.6.5 and have the same thing, that’s strange, I remember when I worked on first test that ctrl-H matched camera view, I’m probably wrong…
ctrl-H is the same size than 100%, but 100% is not:
100% of the, picture relative to screen size (pixel scale picture/screen 1:1)
100% of the picture in the canvas viewport
100% of the camera view in the viewport or screen
I should probably report a bug about 0.6.5 instead or I perhaps missed some informations?
Reset view or 100% is not a state where you necessarily can see the entire image, the canvas area would have to be that big for that to be possible. That’s the expected behaviour afaik though one could argue whether it would be better if 100% always was related to 100% of the image in the canvas viewport.
I understand, but it’s even not a 1:1 pixel scale here. I believe there are some errors in computation. I join the pclx file. And a pictures with more defails, my screen resolution is 1920×1080 (Edit: I made an error in the picture: 1900×1080 == 1920×1080).
What is displayed in the canvas view, when 100% is ~720×480 and so in this case, my 1920×1080 screen match about 1000×550 pixels of the picture, not 1920×1080 pixels.
The computation is correct, the reason you see all that white space is because you’ve zoomed the camera layer, which affects the exported view. The image is 1920x1080 but the camera has been zoomed out, making the painted area look smaller.
if you look at the passpartout, which can be shown when zooming out on the bitmap layer, then it matches the exported image, ie. the white space.
:
however I just didn’t want to miss the momentum as I had a bit of free time to test.
