Hi there - I'd like to know if this is still happening in a recent Windows build of MyPaint using GTK3. I assume it isn't, since only GTK2 is mentioned as showing the bug.

-------------------

This bug tracker will shortly be moving to github. As part of this
process, we're reviewing old bug reports on gna.org. Please
respond so that we know this bug is still live.

https://github.com/mypaint/mypaint/issues for the mypaint app, or
https://github.com/mypaint/libmypaint/issues for its brushlib

Using TumaGonx's latest Windows build (from this page: opensourcepack.blogspot.com/2013/01/mypaint-and-pygi.html ) I've been able to observe the problem on my machine (Windows 8 64 bit).

The "GTK2 version" is the one which makes this bug to occur.
After fiddling around I discovered that there are couple workarounds to it which might helpful in identifying the source of this problem:

--------
Number 1
--------

1) Put the stylus down on the canvas (= begin a painting stroke)
2) While the cursor is still painting press [spacebar] to pull out the popup menu
3) Without lifting the stlys, press the Escape key to remove the popup menu

After the last step it becomes possible to continue the stroke without lag and line breakage. In the process, in the debug window it seems as if MyPaint cycles in and out WINTAB libraries.

It seems that if a stroke has already been started when Wintab libraries are invoked, the stroke won't lag or break, so there probably is a bug somewhere there, in the way MyPaint handles this.

--------
Number 2
--------

The same can also be performed in this way, although it probably only works on Intuos tablets (with the tilt function enabled):

1a) Open MyPaint 1.1 GTK2 from TumaGonx's binary build
2a) Click Help>Debug>GTK Input Device Dialog
3a) Click on [Device: WACOM Tablet Pressure Stylus]
4a) Under "Axes" set Pressure to 4 (tilt X) instead of 3

From now on, if the following steps are performed:

1b) Click once on the canvas
2b) Move the pointer away from the MyPaint window
3b) Move the pointer back again on the canvas

the stroke will be continuously drawn without lagging or breaking up. The only thing is that since pressure is now mapped on the X tilt, it will keep drawing forever. And of course, this is not a very practical behavior for digital painting/drawing.

Clicking once again with the stylus tip on the canvas makes subsequent strokes lag and break again. Repeat the [b] steps above to temporarily stop the lag issue again.

Likely duplicate of this bug: bug #20410

@wolthera

IMO jonnor know it better what to do, or at least let the refactor done first, then we can find the non-breaking workaround for windows.

Has there been any news on this bug yet?

While I don't wish to push the issue, I would be very sad if this meant the end of mypaint on windows :x
(Ubuntu is buggy as fuck on my computer, hence why)

Added jonnor to CC. Hm... maybe the tablet event handler was moved into a different (child) widget, thus triggering different GTK+ bugs than before?

I decided to clone readonly mypaint git and play with checkout to track down when the last pressure work.

Last working: Andrew Chadwick committed 2dc0c42
Broken with: jonnor committed 7a20f20

Any idea? looks like related.

Since linux works, the old bug may not fully fixed for windows, but at least there might easier workaround if upstream fix take too long :)

also tried gtk 2.4.10 but no luck

Comparing with the old bug, which changing devices since first time get into canvas and keep like this, additionally there is coordinates change (drawing a straight will result a heartbeat pattern instead).

The current bug doesn't reproduce above.

"it can't calmed down (changed device back and forth) afterward"
even when not doing any stroke

just for information, i did benchmark-fixed-tiled-surface, the result is
time spent: 20.629039

CPU: E2160 @2.25Ghz RAM: 2G

I try to use mypaint version 1.0's gtk runtime (just in case) with the git version and look at input device test window.

Similar to what wolthera said, initially it shown as tablet, navigate outside canvas change it to CorePointer (as expected) and it remain calm during the transition, but as soon as I start a stroke, it changed to CorePointer, the break/lag happen and it can't calmed down (changed device back and forth) afterward, only when i move it outside canvas, it will calm down.

Actually, I looked at the test-input devices dialogue: Something quite interesting is going on.

It doesn't flicker between wacom-driver and core pointer as expected.

Instead, what happens is that it shows 'core pointer' and when I press down with the stylus, it lags(no messages shown) and then suddenly the hapering stroke appears along with some data on the screen. It was still set to the core-pointer. Testing it again, I did get it to show the wacom driver in the screen, but the result was the same. (When I lift my stylus away from the screen after setting the stroke, it will revert to the core pointer when the stroke is processed.)

I checked it the 'working copy' I had, and there the device was the wacom-driver. To make sure everything was the same, I set it to the core pointer. I had some trouble getting it to the core pointer, (mypaint didn't want to recognise my button clicks) and when I got it to work, I noticed that I had similarly trouble getting the wacom driver to be recognised again. When it finally did respond to the clicks, it also drew all the lines I had been making with the wacom pen in hopes of getting it to be recognised, in a hapered style like the lines I get in the newer version.

I don't know if these events are related or that it's two seperate bugs with the device-changing.

If required, I can attempt to make a screen-capture video of the motions and the test-device output.

I have attached the PNG profile generated from profile_fromgui_a.pstats, just so everyone can see what whe are talking about. In particular, note that there are 343 calls to device_changed_cb(), which is way too many.

I have also noticed that the end_atomic() performance seems to be notably slower in git than in 1.0.0 (just a feeling, no measurement yet). Now this has probably to do with brushlib/ changes. But that would not affect performance while painting.

(file #16374)

You can also use the Help->Debug->Test Input Devices dialog to confirm that the device change is indeed the problem.

If it is the bug that I have described, then you should see the "Device" label in that dialog change very fast forth and back while making a stroke. It would be interesting to know between which labels it changes back and forth.

I doubt that any code inside brushlib/ could cause spontaneous device changes, I think that code doesn't even know about different devices, but who knows...

The different date is when I do full rebuild to satisfy libcms dependency. Both libgtk-win32-2.0-0.dll however built from same source repo. Difference in size could because of different GCC. Anyhow it's unrelated to the bug.

@wolthera library.zip represent part of python 2.6's files and part of mypaint's python files. So you can't interchange it.

if this bug really windows specific (only when pressure-sensitive device present), I'd suspect some native code in brushlib folder may didn't do the windows-aware way or sort of.

are you talking about the file named 'libgtk-win32-2.0-0'?

In that case, someone made a versioning snafu: Both files are 2.24.8.0, but the tumagonx version is edited last on 14th of july and the previous version 1 of december last year. Replacing one by the other doesn't help.

Actually, I tried to backup all files(by rename) and replace them with previous versions. Didn't work either.

There's this lovely file called 'library.zip', which is filled with *.pyo files, in both versions. Doing a rename and then putting in the old version results in mypaint not wanting to start up at all.
Attempting to download a copy from the gtk+ website and replacing the dll's results into nothing either. (Can't find the libgtk-win32-2.0-0 between those downdloads anyhow)

Unless that is the completely wrong dll I'm looking at.

The profiles shows exactly what I expected from your description: MyPaint is busy processing hundreds of device change events.

This is a Windows specific GTK+ tablet support bug, which I spent some time to help debugging some time ago. The problem is that MyPaint gets both events from the tablet and from the "mouse" when you only use the tablet. Here is the bugreport: https://bugzilla.gnome.org/show_bug.cgi?id=653437

The fix committed into GTK+ by Alexander Larsson actually did fix this "device change" problem on my Windows Vista test system. AFAIK Tumagonx has built the release with that version.

So, maybe some of the newer Windows releases ship with a wrong (too old) GTK+ library again? To figure out what is going on, please check the version of the GTK+ DLL for both versions of MyPaint (I think you see it when you hover over the file with the mouse). You can also try to replace the DLL with a newer version.

It is of course also possible that the bug was not actually fixed in all cases, or that the fix doesn't work with the newest wintab version, Windows version, or similar... but first check the DLL version.

Alright. I made them.

file a is just me drawing with some brushes on the canvas. I switch between them occasionally, all in all the brushes aren't terribly complicate.

File b is me playing with the sliders in the colours menu:
First a handful of circles on the HCY wheel, then on the slider next to it. Same with the HSV wheel.
Touched a couple of swatches on the swatch pallet.
Then I used the generic gtk wheel. I circled a bit on the triangle and then on the colour wheel.
Same with hsv cub and I used each of the component slider.
Bit of detail: With slow I mean that the colour-cursor doesn't follow my input cursor when I drag over the wheel. Incidentally, the swatches and the generic gtk wheel work as expected.

File c is me drawing a line and then checking if the colour-changer is working.(Both washed out and crossbowled.) They both work as expected.
I also checked the brush-list changer embedded in the top menu(which is a little slow in wswitching) and the colour menu in the top menu, which again works perfectly.

I also checked everything else, but didn't record that, as they seem to be working at expected speed. Though, I think it's notable that aside from the gtk colour triangle, all the other objects only require one click instead of click and drag with the cursor.
These profiles where made with the stylus.(wacom isd driver)

More interestingly, when using the mousepad, everything works perfectly speedy(even though it still uses up the same large amount of processing power in usage). Inputwise mypaint registers it as the core pointer.
Touchinput(again, wacom isd drivers), while speedy when drawing is slow again on the sliders. Mypaint registers it as the core pointer as well. It also uses up a large amount of processing power.

If you want me to make profile with the latter two, just mention it, but this should be everything, right?

(file #16156, file #16157, file #16158)

What buttons do you mean when you say "When I try using the buttons, they barely respond."? Stylus buttons, buttons with a mouse, or gui ones?

It'd be interesting to see the profile_fromgui.pstats files generated by speedy and slow versions, and compare them to Linux ones for, e.g.:

1. Bind "Help > Debug > ... (cProfile)" to a key of your choice, backtick for example,

2a. backtick - pen down - 5 seconds of drawing - pen up - backtick

2b. backtick - 5 seconds of tweaking colours with an adjuster you find slow - backtick

Both 2a and 2b should generate a file named "profile_fromgui.pstats" in the current working directory, wherever that is on a Windows build. The files contain information about the installation path and details of your home area, but you could attach them here if you're OK with that. Please explain which one refers to which action :)

(You might get an exception because the end-profiling command tries to invoke programs which will probably only exist on a Linux machine - if it mentions os.system, that can be safely ignored)

Tested it a little further:
The recent build is just slow. really slow.

Colour pickers work perfectly, but when I try using the sliders they respond very slowly as well. When I try using the buttons, they barely respond.

When I compare the processor use on both versions by constantly drawing a line and looking at the task manager in the meantime:
Old version: barely 4%
New version: 26%
Ram usage of both is normal.

After testing the new colour picking methods on ubuntu I went back to windows and downloaded tumagonx's release on this page:

forum.intilinux.com/mypaint-development-and-suggestions/mypaint-for-windows-new-version/
(In the fifth post.)

Testing it out, I find that whenever I use a brush, it responds very slowly and then when it does show it breaks up the stroke.

It FEELS as if the program is having trouble registering the brushstrokes?

I did update my drivers(wacom isd, have a tablet pc) recently, which resulted in 64b programs now recognising pressure sensitivity as well. But when I test previous 32b and 64b version of mypaint it works as expected, and partha's release of the gimp works as well, so I don't think the problem lies there.

I included a picture with comparison.