bugMyPaint - Bugs: bug #19948, [Windows]Brushstrokes lag and...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #19948: [Windows]Brushstrokes lag and break up

Submitted by:  wolthera <thera>
Submitted on:  Mon 16 Jul 2012 09:59:39 AM UTC  
Votes:  1  
 
Severity: 3 - NormalPriority: 5 - Normal
Status: Need InfoPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: git (3rd party build from Tumagonx)Planned Release: None
Operating System: windows 7

(Jump to the original submission Jump to the original submission)

Thu 17 Jul 2014 04:38:14 PM UTC, comment #19:

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

Andrew Chadwick <achadwick>
Project Administrator
Mon 04 Feb 2013 04:40:57 PM UTC, comment #18:

Using TumaGonx's latest Windows build (from this page: http://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.

s12a <s12a>
Mon 07 Jan 2013 05:38:23 PM UTC, comment #17:

Likely duplicate of this bug: bug #20410

Martin Renold <martinxyz>
Project Administrator
Thu 20 Sep 2012 12:31:56 PM UTC, comment #16:

@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.

Bakhtiar <tumagonx>
Project Administrator
Thu 20 Sep 2012 11:55:07 AM UTC, comment #15:

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)

wolthera <thera>
Mon 13 Aug 2012 04:40:34 PM UTC, comment #14:

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

Martin Renold <martinxyz>
Project Administrator
Mon 13 Aug 2012 12:26:35 PM UTC, comment #13:

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

Bakhtiar <tumagonx>
Project Administrator
Sun 12 Aug 2012 01:22:43 AM UTC, comment #12:

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.

Bakhtiar <tumagonx>
Project Administrator
Sun 12 Aug 2012 12:59:03 AM UTC, comment #11:

"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

Bakhtiar <tumagonx>
Project Administrator
Sun 12 Aug 2012 12:45:19 AM UTC, comment #10:

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.

Bakhtiar <tumagonx>
Project Administrator
Sat 11 Aug 2012 09:09:40 PM UTC, comment #9:

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.

wolthera <thera>
Sat 11 Aug 2012 06:41:32 PM UTC, comment #8:

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)

Martin Renold <martinxyz>
Project Administrator
Sat 11 Aug 2012 06:30:07 PM UTC, comment #7:

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...

Martin Renold <martinxyz>
Project Administrator
Sat 11 Aug 2012 03:57:56 PM UTC, comment #6:

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.

Bakhtiar <tumagonx>
Project Administrator
Wed 08 Aug 2012 08:13:10 PM UTC, comment #5:

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.

wolthera <thera>
Wed 08 Aug 2012 05:26:38 PM UTC, comment #4:

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.

Martin Renold <martinxyz>
Project Administrator
Sat 21 Jul 2012 12:52:18 PM UTC, comment #3:

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)

wolthera <thera>
Fri 20 Jul 2012 10:52:43 PM UTC, comment #2:

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)

Andrew Chadwick <achadwick>
Project Administrator
Mon 16 Jul 2012 10:28:47 AM UTC, comment #1:

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.

wolthera <thera>
Mon 16 Jul 2012 09:59:39 AM UTC, original submission:

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

http://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.

wolthera <thera>

 

Attached Files
file #16374:  profile_fromgui_a.png added by martinxyz (774kB - image/png)
file #16156:  profile_fromgui_a.pstats added by thera (145kB - application/octet-stream - debug gui profiles as requested.)
file #16157:  profile_fromgui_b.pstats added by thera (171kB - application/octet-stream - debug gui profiles as requested.)
file #16158:  profile_fromgui_c.pstats added by thera (130kB - application/octet-stream - debug gui profiles as requested.)
file #16112:  mypaint_buggy.png added by thera (371kB - image/png - comparison of the brush strokes between a git version of mypaint from around april and the recent build by tumagonx)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by s12a (Posted a comment)
  • -unavailable- added by doozer88 (Voted in favor of this item)
  • -unavailable- added by martinxyz
  • -unavailable- added by jonnor (Updated the item)
  • -unavailable- added by martinxyz
  • -unavailable- added by tumagonx (Posted a comment)
  • -unavailable- added by martinxyz
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by thera (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 1 encouragement so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 11 Jan 2013 06:52:04 AM UTCdoozer88Carbon-Copy-=>Added doozer88
    Mon 07 Jan 2013 05:38:23 PM UTCmartinxyzCarbon-Copy-=>Added s12a
    Sat 05 Jan 2013 01:34:45 PM UTCjonnorSummaryBrushstrokes lag and break up on windows=>[Windows]Brushstrokes lag and break up
    Mon 13 Aug 2012 04:36:02 PM UTCmartinxyzCarbon-Copy-=>Added jonnor
    Sat 11 Aug 2012 06:41:32 PM UTCmartinxyzAttached File-=>Added profile_fromgui_a.png, #16374
    Wed 08 Aug 2012 05:30:19 PM UTCmartinxyzCarbon-Copy-=>Added tumagonx
    Sat 21 Jul 2012 12:52:18 PM UTCtheraAttached File-=>Added profile_fromgui_a.pstats, #16156
      Attached File-=>Added profile_fromgui_b.pstats, #16157
      Attached File-=>Added profile_fromgui_c.pstats, #16158
    Fri 20 Jul 2012 10:52:43 PM UTCachadwickStatusNone=>Need Info
      Releasegit=>git (3rd party build from Tumagonx)
    Mon 16 Jul 2012 09:59:40 AM UTCtheraAttached File-=>Added mypaint_buggy.png, #16112
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup