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 17 May 2013 10:42:16 AM UTC  
 
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 23 Jun 2014 09:58:25 PM UTC, 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:

https://github.com/mypaint/mypaint/issues
https://github.com/mypaint/libmypaint/issues

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed 23 Oct 2013 12:57:17 AM UTC, 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
https://gitorious.org/mypaint/mypaint/commit/e6092eb3ac1c40eafbd535aeed72e28f62a2edd7/diffs/877108796deb007a18cbc8c4f3a5dbdd194471d9

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 22 Oct 2013 08:19:49 AM UTC, 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 21 Oct 2013 07:17:06 PM UTC, 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 21 Oct 2013 12:28:30 PM UTC, 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.

https://gitorious.org/mypaint/achadwick-mypaint/commits/eventhack-wip

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 20 Oct 2013 06:29:37 PM UTC, 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 20 Oct 2013 04:01:41 AM UTC, 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.

https://gitorious.org/mypaint/achadwick-mypaint/commits/eventhack-wip

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

+verbatim-
$ 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)
[...]
-verbatim-

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 05 Aug 2013 08:55:43 AM UTC, 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 05 Aug 2013 08:48:06 AM UTC, 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 05 Aug 2013 05:29:45 AM UTC, comment #10:

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

Martin Renold <martinxyz>
Project Administrator
Sun 16 Jun 2013 01:49:57 PM UTC, 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 15 Jun 2013 08:51:13 AM UTC, comment #8:

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

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

Reproducible on Arch Linux. What an annoying optimization.

Jon Nordby <jonnor>
Project Administrator
Tue 11 Jun 2013 12:44:01 PM UTC, 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 20 May 2013 08:05:57 AM UTC, 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 17 May 2013 06:38:46 PM UTC, comment #4:

Yes, we switched from GTK2 to GTK3 in git.

Martin Renold <martinxyz>
Project Administrator
Fri 17 May 2013 05:39:56 PM UTC, 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 17 May 2013 05:30:13 PM UTC, 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 17 May 2013 05:22:51 PM UTC, 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:

http://wiki.mypaint.info/Development/Debugging_Tablet_Issues#Testing_GTK3_tablet_support

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 17 May 2013 10:42:16 AM UTC, 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.

     

    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
    Mon 23 Jun 2014 09:58:25 PM UTCachadwickOpen/ClosedOpen=>Closed
    Wed 23 Oct 2013 12:57:17 AM UTCachadwickStatusReady For Test=>Fixed
    Sun 20 Oct 2013 04:01:41 AM UTCachadwickStatusIn Progress=>Ready For Test
      Assigned tomartinxyz=>achadwick
    Mon 05 Aug 2013 08:48:06 AM UTCachadwickAttached File-=>Added devicehacks.patch, #18640
    Sun 16 Jun 2013 01:49:57 PM UTCmartinxyzStatusConfirmed=>In Progress
    Sat 15 Jun 2013 11:48:03 AM UTCmartinxyzAssigned toNone=>martinxyz
    Sat 15 Jun 2013 08:51:13 AM UTCmartinxyzStatusWorks For Me=>Confirmed
    Wed 12 Jun 2013 06:46:38 PM UTCjonnorSummaryMypaint built from Git and using gtk3 has slow pen tracking=> Slow pen tracking when using GTK+ 3.8 or later
    Mon 20 May 2013 08:05:57 AM UTCtigertAttached File-=>Added mypaint-gtk3-input.png, #17982
    Fri 17 May 2013 05:22:51 PM UTCmartinxyzStatusNone=>Works For Me
    Fri 17 May 2013 10:42:16 AM UTCtigertAttached File-=>Added pen-tracking-speed.jpg, #17973
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup