bugMyPaint - Bugs: bug #20822, Slow pen tracking when using GTK+...

Show feedback again

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

bug #20822: Slow pen tracking when using GTK+ 3.8 or later

Submitted by:  Tuomas Kuosmanen <tigert>
Submitted on:  Fri May 17 10:42:16 2013  
Severity: 3 - NormalPriority: 5 - Normal
Status: FixedPrivacy: Public
Assigned to: Andrew Chadwick <achadwick>Open/Closed: Closed
Release: 1.1.0+gitPlanned Release: None
Operating System: Linux (Fedora 19)

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

Mon Jun 23 21:58:25 2014, comment #19:

[This is a canned response, please forgive the broken formatting: it's one of the many things Gna! unfortunately does not do well.]

This bug tracker will shortly be moving to Github. As part of this process, we are reviewing old bug reports on gna.org.

This bug was marked as Fixed long ago, but was still classified as Open. Github does not distinguish between Fixed+Open and Fixed+Closed in the
way we once did here, so this bug is now being marked Closed, and will not be migrated into the github issues tracker.

If you believe that this bug still affects the most recent git master of MyPaint (and thus the next release), please feel free to open a new
issue on Github about it. Our new issue trackers are:


Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed Oct 23 00:57:17 2013, comment #18:

Thanks for all the testing on this. I've had no reports of any regressions, and event processing rates are now comparable with 1.1.0 (not git, GTK2). So that's a win, I think.

Pushed to master

I'm most concerned about pressure and tilt smoothness now. For the eventhack-captured events, these axes are faked as linear interpolations of the "real" axis values to either side (we use the real x and y values, however). It's possible that linear interpolation is insufficiently smooth here: I could try a spline-based interpolation instead. Catmull-Rom won't work for this unfortunately: we'd need two successive "real" events in the recombined stream to make it work, and that can't be guaranteed in a timely fashion.

If pressure looks stripey (when it varies opacity) or staircasey (when pressure adjusts the brush radius) when it wouldn't with earlier GTK2 revisions, I'd like to know. Can try fancier splines, but please report such regressions as a separate bug ☺

This won't break for Windows people, but someone will have to write some Win32-specific workaround code to get events at the rate the tablet is reporting them. Windows patches would be very welcome. Please look in lib/eventhack.hpp to see how we do it for X11 and see the docs for gdk_window_add_filter().

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Tue Oct 22 08:19:49 2013, comment #17:

This works wonders for me too. Thanks a lot for working on this, Andrew (and any others involved)!

DEBUG: gui.application: Device change: name='Wacom Intuos5 touch M Pen stylus' source=GDK_SOURCE_PEN
DEBUG: gui.canvasevent: Processing at 121 events/s (t_avg=0.008s)
DEBUG: gui.canvasevent: Processing at 197 events/s (t_avg=0.005s)
DEBUG: gui.canvasevent: Processing at 198 events/s (t_avg=0.005s)
DEBUG: gui.canvasevent: Processing at 199 events/s (t_avg=0.005s)
DEBUG: gui.canvasevent: Processing at 200 events/s (t_avg=0.005s)
DEBUG: gui.canvasevent: Processing at 199 events/s (t_avg=0.005s)

Tuomas Kuosmanen <tigert>
Mon Oct 21 19:17:06 2013, comment #16:

This is making a massive difference. I'm now getting about 175 events per second on average, sometimes more and sometimes less but it's definitely very usable now.

Ryan Hasse <ryanhasse>
Mon Oct 21 12:28:30 2013, comment #15:

Looks like Ubuntu systems are threaded at event filtering time. Oops.

Fix pushed: the segfault should be gone in c6e1041 on eventhack-wip. Could anyone testing pull and retest please? Many thanks.


Still interested to know what event delivery rates people are getting per second with GTK 3.8+ with this branch, and whether lines are acceptably smooth. Invoking this branch with

$ MYPAINT_DEBUG=1 ./mypaint -c /tmp/cfgtmp_evhack.$$

after rebuilding it should make the rate evident in the debug messages. 200 events per second is the rate we used to get with PyGTK and GTK2.0 with good tablets. The artificial maximum imposed by GTK 3.8+ is whatever your screen refresh rate is, typically 50 to 60 events per second, so anything above that is a win and indicates that events are being captured correctly by the filter.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Oct 20 18:29:37 2013, comment #14:

It opens briefly and then gives a segmentation fault. Here's what debug spit out:

INFO: mypaint: Debugging output enabled via MYPAINT_DEBUG
DEBUG: gui.gtk2compat: Using GTK3
DEBUG: lib.helpers: Using builtin python 2.6 json support
DEBUG: mypaint: getlocale(): ('en_US', 'UTF-8')
DEBUG: mypaint: localepath: 'po'
DEBUG: mypaint: localepath_brushlib: 'brushlib/po'
CRITICAL: gui.main: Test critical message, please ignore
DEBUG: gui.main: user_datapath: u'/tmp/cfgtmp_evhack'
DEBUG: gui.main: user_confpath: u'/tmp/cfgtmp_evhack'
INFO: gui.application: Created basedir u'/tmp/cfgtmp_evhack'
INFO: gui.application: Created data subdir u'/tmp/cfgtmp_evhack/backgrounds'
INFO: gui.application: Created data subdir u'/tmp/cfgtmp_evhack/brushes'
INFO: gui.application: Created data subdir u'/tmp/cfgtmp_evhack/scratchpads'
DEBUG: gui.workspace: Adding GtkScrolledWindow around canvas
DEBUG: gui.document: Mode changed: <ModeStack [SwitchableFreehandMode]>
INFO: gui.brushmanager: Merging upstream brush changes into your collection.
DEBUG: gui.workspace: Completing layout (mapped)
INFO: gui.application: Looking for GTK devices with pressure
INFO: gui.application: Setting GDK_MODE_SCREEN mode for 'HA60S stylus'
DEBUG: gui.canvasevent: Adding evhack filter (<TiledDrawWidget object at 0x32b2050 (TiledDrawWidget at 0x35fe660)>, <gui.canvasevent.SwitchableFreehandMode object at 0x32bbbd0>)
DEBUG: gui.application: Device change: name='HA60S stylus' source=GDK_SOURCE_MOUSE

Ryan Hasse <ryanhasse>
Sun Oct 20 04:01:41 2013, comment #13:

There has been no movement on the GTK bug, so I've implemented capturing the missing events as a GDK event filter. I'm now getting up to 200 events per second now and smooth lines with my Intuos5.


The code will only work on X11 at present, but compilation and runtime is suitably conditional.

$ cd path/to/my/mypaint/clone
$ scons --clean
$ git remote add achadwick git://gitorious.org/mypaint/achadwick-mypaint.git
$ git fetch achadwick
$ git co -b eventhack-wip achadwick/eventhack-wip
$ scons
$ MYPAINT_DEBUG=1 ./mypaint -c /tmp/cfgtmp_evhack
DEBUG: gui.canvasevent: Adding evhack filter (<TiledDrawWidget object
at 0x3ba9d20 (TiledDrawWidget at 0x30065a0)>,
<gui.canvasevent.SwitchableFreehandMode object at 0x518c6d0>)
DEBUG: gui.canvasevent: Processing at 200 events/s (t_avg=0.005s)
DEBUG: gui.canvasevent: Processing at 199 events/s (t_avg=0.005s)

Please can everyone test and report the speeds they get for continuous scribbles when running with MYPAINT_DEBUG turned on? Thanks.

Commit 451ca93 in that branch is a good point to contrast it against if you think you're getting no improvement.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Aug 5 08:55:43 2013, comment #12:

heh. Please ignore the "|| 1" testing junk in the conditional part of that patch ☺

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Aug 5 08:48:06 2013, comment #11:

Regarding gdk_device_get_history: I tried it. It's not supported by PyGI presumably due to the GdkTimeCoord***, but it's trivial to write our own based on PyGTK's _wrap version: attached, patches commit 2623bc3.

Like yusuke494 on gtkforums, it always returns FALSE for me, for fairly serious and recent Wacom kit (an Intuos 5), recentish xserver-xorg-input-wacom (0.15.0+20120515, Debian testing (xserver-xorg 1:7.7+3, xserver-xorg-core 1.12.4-6), and with 'Option "HistorySize" 200' thrown in the relevant InputClass+Match for the hell of it (which isn't the default, doesn't work, and is recorded as having been removed in a changelog somewhere IIRC). I gave up trying with it at roughly that point, but let me know if it works for you guys.

(file #18640)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Mon Aug 5 05:29:45 2013, comment #10:

Duplicate: https://gna.org/bugs/?21003

Martin Renold <martinxyz>
Project Administrator
Sun Jun 16 13:49:57 2013, comment #9:

I don't think it's possible to fix this one in MyPaint. Opened a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=702392

Martin Renold <martinxyz>
Project Administrator
Sat Jun 15 08:51:13 2013, comment #8:

I can reproduce with GTK+ 3.9.2. (Works fine with GTK+ 3.4.2.)

Martin Renold <martinxyz>
Project Administrator
Wed Jun 12 18:46:38 2013, comment #7:

Reproducible on Arch Linux. What an annoying optimization.

Jon Nordby <jonnor>
Project Administrator
Tue Jun 11 12:44:01 2013, comment #6:

Some input for this problem: Apparently there were changes in xinput handling on Gtk 3.8, so this is going to hit everyone else soon. Many people have 3.6 still and thus the problem won't manifest itself.

From #gtk channel on gimpnet:
15:37 < alex> tigert: In Gtk 3.8 consecutive motion events are tossed away and
you only get the last one for the frame you're drawing.
15:38 < alex> tigert: If you want the whole history for the frame there is some
per-device history
15:38 < alex> gdk_device_get_history() i think
15:38 < tigert> alex: I wonder why this is not a problem for everyone then?
15:39 < alex> Yeah, its a bit extreme for you
15:39 < alex> i mean, if its repainting at 60hz you should get better than that
15:40 < tigert> this is fedora 19
15:40 <@Company> 3.8
15:40 < tigert> ah right
15:40 <@Company> F19 already qualifies :)
15:40 <@Company> i think ubuntu has 3.6 or so
15:41 <@Company> and 3.8 started with the more aggressive compression

Tuomas Kuosmanen <tigert>
Mon May 20 08:05:57 2013, comment #5:

Yeah, test input devices -dialog reports more like 35ms spacing for events. Attached the screenshot, the text log was pretty impossible to grep, thus I took a screenshot of the debug dialog. Sorry about that :P

(file #17982)

Tuomas Kuosmanen <tigert>
Fri May 17 18:38:46 2013, comment #4:

Yes, we switched from GTK2 to GTK3 in git.

Martin Renold <martinxyz>
Project Administrator
Fri May 17 17:39:56 2013, comment #3:

I downloaded the 1.1 release tarball - it does not exhibit the slow tracking issue, so there's something that happened since 1.1 release and git master that apparently causes this?

Tuomas Kuosmanen <tigert>
Fri May 17 17:30:13 2013, comment #2:

Your test image looks a bit like when you have a low-resolution timestamp for tablet events.

When you open the "test input devices" dialog from the debug menu, and you draw very fast circles, you should see roughly 100 events per second with a wacom tablet, and the "timestamp spacing" values should all be very small (around 10ms).

But it could also be something else.

Martin Renold <martinxyz>
Project Administrator
Fri May 17 17:22:51 2013, comment #1:

The input dialog is no longer provided by GTK3, so I removed it.

If you can, please compile the GTK3 tablet test application, and see if you can reproduce your problem with it. See here:


Needless to say, strokes work fine here with GTK3. There must be something different in your setup compared to mine.

Martin Renold <martinxyz>
Project Administrator
Fri May 17 10:42:16 2013, original submission:

See test image. Same setup, drawing quick strokes with Mypaint 1.0.0 results in pretty much perfect tracking of the pen strokes, but after I built MyPaint from git, the new version is slower, looks like it is dropping events and thus results in jagged strokes. Looks like the new one is using gtk3 (Debug -> GTK input dialog throws an exception)

Tuomas Kuosmanen <tigert>


Attached Files
file #18640:  devicehacks.patch added by achadwick (3kB - text/x-patch)
file #17982:  mypaint-gtk3-input.png added by tigert (187kB - image/png)
file #17973:  pen-tracking-speed.jpg added by tigert (77kB - image/jpeg)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by ryanhasse (Posted a comment)
  • -unavailable- added by achadwick (Updated the item)
  • -unavailable- added by jonnor (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by tigert (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 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Jun 23 21:58:25 2014achadwickOpen/ClosedOpen=>Closed
    Wed Oct 23 00:57:17 2013achadwickStatusReady For Test=>Fixed
    Sun Oct 20 04:01:41 2013achadwickStatusIn Progress=>Ready For Test
      Assigned tomartinxyz=>achadwick
    Mon Aug 5 08:48:06 2013achadwickAttached File-=>Added devicehacks.patch, #18640
    Sun Jun 16 13:49:57 2013martinxyzStatusConfirmed=>In Progress
    Sat Jun 15 11:48:03 2013martinxyzAssigned toNone=>martinxyz
    Sat Jun 15 08:51:13 2013martinxyzStatusWorks For Me=>Confirmed
    Wed Jun 12 18:46:38 2013jonnorSummaryMypaint built from Git and using gtk3 has slow pen tracking=> Slow pen tracking when using GTK+ 3.8 or later
    Mon May 20 08:05:57 2013tigertAttached File-=>Added mypaint-gtk3-input.png, #17982
    Fri May 17 17:22:51 2013martinxyzStatusNone=>Works For Me
    Fri May 17 10:42:16 2013tigertAttached File-=>Added pen-tracking-speed.jpg, #17973
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup