New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brush strokes are lagging (1.2.0-beta) #390

Open
AnomalousG opened this Issue Aug 2, 2015 · 118 comments

Comments

Projects
None yet
@AnomalousG
Copy link

AnomalousG commented Aug 2, 2015

Samsung ATIV 700T Windows 8.1 64bit running MyPaint 64bit.

My brush strokes are lagging significantly. Tumagonx's 1.2.0 release (mypaint-1.2.0a.7z (GTK 3.14.13 + Anti-Art's experimental brush settings + brushpack , July 3, 2015)) is present on the same system and does not lag. His release was never 'installed' but simply extracted to the Downloads folder and runs quite well even with the current beta release installed and lagging.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 2, 2015

@AnomalousG what do you mean by "lagging"? Do you have a video or something you can share?
Also,

  • Please paste the exact version numbers of the builds you are testing, from Help→About MyPaint
  • What kind of tablet are you using, and have you got the very latest drivers for it installed?
  • Have you tried "MyPaint w32" instead?

@tumagonx Sounds like there's either a specific patch of yours, specific build options, or a GTK regression upstream we should be chasing?

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Aug 2, 2015

I don't think it is AntiArt patch related, most likely a GTK regression?
I've not tried 3.16.x so far.

@AnomalousG maybe a video would be helpful?

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Aug 2, 2015

Just in case,
my compile optimization: -Os -msse2 -mfpmath=sse
I don't use optimized blas for numpy.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 2, 2015

Works for me using 1.2.0-beta.0.97+gitexport.d3658b5, and building with the canned msys2 build with the docs and scripts in \windows. Currently this uses GTK 3.16.6.

  • You will see lag if you have a very underpowered computer. The code tries to capture events as fast as they come in, so it delegates forwarding to the brush engine to a separate low-priority task (in the main GTK thread). If I cap CPU usage at <50% for my test/build VM, I start seeing the effects very readily.
  • We're using winpthreads and -O3 -fopenmp -pthread, which are on by default in this toolchain. Could easily turn that off for Windows builds - msys2 had winpthreads-related brokenness recently, and its winpthreads is pretty experimental.
@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 2, 2015

Anyway - on this test VM I'm using the Wacom drivers at 6.3.13-w3, up-to-date virtual USB passthrough, and an Intuos5 tablet (PTH-650). It's slower than the host OS's behaviour, but then it's only using 2 cores for Win7. Drawing is acceptable when the virtual CPUs are not capped.

Host: Intel® Core™ i7-4510U CPU @ 2.00GHz × 4

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 2, 2015

@tumagonx
@achadwick

Both Google Drive and Dropbox links to the same video provided below. All version numbers and specs are shown in the video and listed below for clarity.

Running on a Samsung ATIV PC Pro 700t running a core i5 CPU @ 1.7GHz (this machine runs the latest Krita and Gimp easily). To answer achadwick's question, I did try the 32bit version and I suffered the same laggy/stuttery experience. Again, Tumagonx's 1.2.0 release gives me a 'normal' experience. All Windows and Wacom updates current.

https://drive.google.com/file/d/0BwokwX7gGELYZVIzNjVPZEpOM1U/view?usp=sharing

https://www.dropbox.com/s/t1lspdrd4t73atv/20150802_153503.m4v?dl=0

In case there is a problem reading the text in this compressed video, all relevant text is below.

first version demonstrated:
1.2.0-beta.0.73+gitexport.1932648 (64Bit)
p.s. Also experienced the same probleam with the first beta release (mypaint-w64-1.2.0-beta.0-setup.exe)

Second version demo'ed:
1.2.0-alpha.20150702+git.0762c4f (64Bit)

CPU: i5-3317U @1.2GHz 1.70 GHz

Wacom driver version: 7.2.1-24

extra: Graphics chip is Intel HD 4000, Windows 8.1, 4 GB RAM

Thanks.

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 3, 2015

@tumagonx
@achadwick

Made another video of two versions of MyPaint running on a much older machine, an LE 1700 made by Motion Computing. The website cpubenchmark.net rated the processor of the ATIV 700t at approx. 3100, while rating the LE1700 at approx. 900 (higher is more powerful... but you guys already know that, duh!). Oddly, the hiccup seems more prominent on the more powerful machine. I do have a theory as to why that is. Anyway, this goes to show that the issue is not machine or Windows version specific.

The first segment of the demo contains a few strokes that were inadvertently made outside of the camera's view. My apologies for this. The same pens are used in both segments. A few brushes used are 'slow' brushes, brushes that, based on their individual settings, are set to lag behind the movement of the cursor. Please note that the issue I'm highlighting is not related to this and should be obvious from observing the strokes as they form in the videos provided. There is a noticeable falter or stall, then a rush to complete the rendering of the stroke. Sometimes the rendering of the entire stroke is delayed all together.

The first demo is of the 1.2.0-beta.0.73+gitexport.1932648 (32Bit),
while the second is of 1.2.0-alpha.20150605+git.4e8a6b5 (32Bit)

both links below are of the same file:
https://www.dropbox.com/s/3npq2y875813wgk/20150802_194325.mp4?dl=0
https://drive.google.com/file/d/0BwokwX7gGELYejllUW9vWkFaOHM/view?usp=sharing

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 3, 2015

@AnomalousG Thanks - I think we've successfully ruled out machine differences.

Would you be up for some testing with different build options, since you've got a lot more hardware than I have for this sort of thing? The build instructions for local testing are at

https://github.com/mypaint/mypaint/blob/master/README_WINDOWS.md#manual-building-and-testing

I'd be very interested to know whether scons enable_openmp=no or scons debug=yes make any difference to the lagginess when you run it compared to the standard build. I guess we won't need videos for it at this point!

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 3, 2015

One thing I want to clarify - does the lag only affect tablet input (input events ~200Hz) or does it affect tablet and mouse input (~50-80 Hz) alike?

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 3, 2015

@achadwick I ran a comparison test with a mouse and got the same range of results between the two versions. So, it doesn't seem to matter what input device is used.

One thing I did notice is that, in the task manager, the MyPaint beta builds runs as 'python2w.exe', while tumagonx's alpha builds run as 'mypaint.exe'. Maybe this matters.

I will see about testing with different builds. I'm not a programmer, but neither am I code illiterate. I should be able to muddle my way through.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 3, 2015

I'd be happy to accept a py2exe or whatever patch for windows/build.sh, if it makes this bug go away. However it's not a thing I've used before. My only concern there is that I want there to still be a console-debugging icon installed in the start menu too, so that users can generate better error reports.

@achadwick achadwick referenced this issue Aug 3, 2015

Closed

Colour dropper #369

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Aug 3, 2015

@AnomalousG I also use python2w but renamed for convenience, I didn't use any python bundler because maxy told to keep python sources intact and I think that's good idea for advanced users. The exe stub is standard Setuptools' launcher with mypaint icon.

For libmypaint I use standard, openmp=on debug=off. Winpthreads is from mingw-w64-v3.2.0

@Robsoie

This comment has been minimized.

Copy link

Robsoie commented Aug 6, 2015

I'm no coder at all so forgive inaccurate theories :D, but in the case those build options aren't responsible of that horrible brush lag on win32 and win64 , could it be a library MyPaint use that has a version (latest or not) that is simply very buggy on windows OS ?

I mean, in the past Gimp moved to use the latest Cairo library of that time, and it happened that the latest version of that library was badly broken on the windows OS, leading into horribly laggy brush strokes (that reminded me a lot of what i see in that official mypaint 1.20) , while using older version of that library had brush reacting as they should :
gimpchat.com/viewtopic.php?f=7&t=6418

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 6, 2015

[stage whisper] "one point two point zero!" - but don't sweat it, and thanks for the GIMP link ☺

But yeah. Just a thought on making freehand lag more apparent: MyPaint already makes a rough estimate of events per second on the capture side, visible in debug mode. Art apps need that figure as high as possible for accuracy's sake, so we just shove the events into a queue for later a) stroke rendering, and b) the screen updates you get as a result of the model data changing. Both "a" and "b" process in the main GTK thread, although "a" forwards its work to the C rendering engine which is threaded (via OpenMP) by tile for sufficiently large sets of tiles (big brushes), and "b" uses partially OpenMPified C++ pixelwhacker code to render the layers stack for each updated tile before throwing it over to Cairo.

I need to understand the way the brush engine does its threadified tile access better, but it's clear that it has to write to the tiles that the rendering side needs to read. These don't happen concurrently given that "a" and "b" both process in the main thread, so it's safe! however it's possible that either one might starve the main thread.

We might be able to make a similar draw()s - per - second estimate as well, for debug mode.

(Hope that understanding helps anyone trying different things out)

Cutting to the chase, are things like the frame edit mode affected too? Just moving the frame edges doesn't use the brush engine, and it doesn't queue events like freehand does: it would only be crappified by crappy rendering performance.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 6, 2015

Could an affected Windows user please try setting OMP_NUM_THREADS to 1 i their environment please? Does that make the lag disappear?

@Robsoie

This comment has been minimized.

Copy link

Robsoie commented Aug 6, 2015

EDIT : i didn't noticed there was a new beta available a few hours ago
https://github.com/mypaint/mypaint/releases
So the following was only valid for MyPaint 1.2.0 beta 0.73
I will test the new version when i will have more time tomorrow and report if what i wrote is still valid for the new one.

Hello, no idea if it's helpful, but here's my observations :

  • i added OMP_NUM_THREADS as an environment variable and set it to 1 .
    Then i restarted my computer (not sure if it's needed to make use of newly added environment variable, but at least it was done).

I then launched MyPaint 1.2.0 beta0.73 ( win32 ) and tested (i use a mouse by the way in case it makes a difference) and i observed on the few brushes i tested a big difference :
The brushes are now much less laggy, but still i noticed a delay between where i stroke and where the actual stroke is for the brushes i was testing, it's much better than before but it's not yet as good as in Tumagonx latest build (mypaint-1.2.0a.7z (GTK 3.14.13 + Anti-Art's experimental brush settings + brushpack , July 3, 2015)
Tumagonx brushes strokes are immediate, never lagging behind where your mouse cursor is stroking and as good as they were in much older versions of Mypaint :

If i draw circles very very fast with my mouse with MyPaint 1.2.0 beta0.73 (with the environment variable setup, without it's horribly unworkable anyways) , i can notice those circles tend to be made of lines instead of being smoothly circular, considering the speed i draw it's not unexpected.
But when i use Tumagonx MyPaint 1.2.0a , even when i draw circles very fast, circles are much looking smooth circles with the same brushes, the lines are less obvious.

Additionally with Tumagonx MyPaint 1.2.0a, brushes strokes are immediate, never lagging behind and as good as they were in much older versions of Mypaint.

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Aug 7, 2015

Should I make equal beta version for comparison? atleast with same Gtk. Though it'd be better to focus on the mainline as we get closer to final version.

@Robsoie

This comment has been minimized.

Copy link

Robsoie commented Aug 7, 2015

If you build a new version i would gladly give it a try to see if there's a difference regarding the brush lag/delay.

quick update as i tested with the newest beta (mypaint-w32-1.2.0-beta.1-setup.exe) before falling asleep for what's left of my night.

Before testing, i deleted the OMP_NUM_THREADS environment variable to make a direct test with MyPaint 1.2.0 beta 0.73

After restarting my computer to truly get rid of its possible trace of the variable in my RAM, i started that Mypaint and this new beta looks to work regarding the brush lag like if i was using MyPaint 1.2.0 beta 0.73 with OMP_NUM_THREADS set to 1 , so apparently no need to set it anymore for this new version.

That said, while this new version is much less horribly laggy than MyPaint 1.2.0 beta0.73, it has still that slight brush lag/delay that makes it more painful than enjoyable to work with it, something that is not present in Tumagonx MyPaint 1.2.0a

And i'm not sure if it's related, but i noticed when i change a brush to another in this new version, my first stroke is ignored by the display and only actually display once i release my mouse button, further strokes aren't affected.

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 7, 2015

@achadwick @tumagonx

Sorry for my absence, got caught up.

So, I finally ran the builds on my tablets using both
scons enable_openmp=no
and
scons debug=yes

and noticed no difference in either build. What I have noticed all along is that after using a brush for a few strokes, the problem seems to disappear until you change brushes. If I use a brush until the lag disappears, change brushes and return to this same brush, it will lag again until I've made a few strokes. All brushes seem to stop lagging after a few strokes.

EDIT: Ran them both again. Actually, the scons enable_openmp=no build has noticeably less lag and it doesn't lag predictably. Sometimes it's butter smooth, then seems to lag randomly after changing brushes. It is definitely better than scons debug=yes build.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 7, 2015

Be very sure you're using the same brush in each version, with the same "Slow position tracking" ("Smooth") setting. Ideally, dial that setting down to zero in Tool Options, because it can really confuse debugging something like this.

Re "made of lines": like #35?

@Robsoie and anyone else using the new version: please can you either launch MyPaint in console debugging mode (there's an entry in the Start menu for it in the most recent beta), or use Help→Debug→Test Input Devices and give me an events-per-second count when scribbling in circles as fast as you can. Both versions, for comparison. You should be getting 80-100 events/sec for a mouse or a touchpad, close to 200 events/sec for a tablet.

Also, anyone affected, please turn off automated backups in Preferences (docs: https://github.com/mypaint/mypaint/wiki/v1.2-Backup-Files-and-Autosaves#automated-backups and see if that resolves the issue on an affected version. That kicks in after 10 seconds of inactivity, but the saves can last for several seconds (they're low-priority, so their progress should pause while you're drawing). You should be able to let autosave kick in and draw without too much of a penalty to the event processing rate.

#39 is another similar "made of lines" bug that kicked in at a state change. Does this bug resolve briefly when you pan the canvas, or change to inking mode and back again?

Finally, I'd be interested to know what console debugging says about the "motion event compression workaround" on your systems, and whether it's something other than

DEBUG: gui.freehand: Add motion event compression workaround: using set_event_compression(False) (<TiledDrawWidget object at 0x7f4a4c3c4eb0 (TiledDrawWidget at 0x3649740)>) (was True)

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 7, 2015

@tumagonx Sure, definitely. It'll help decide whether it's GTK or some stupid thing I'm doing. I have to figure out what magic you're using in your builds at some point anyway!

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 7, 2015

@achadwick Here's feedback for you.

Panning didn't help.

Changing stroke mode and returning to freehand didn't help.

The stroke seems to appear just as slowly in inking mode (maybe that's on purpose), while, returning to freehand mode didn't improve anything.

Inking mode always causes an error in the @tumagonx alpha build. Maybe the issue is related to that. Inking mode works fine in beta builds. The inking stroke forms slowly in his build and throws an error almost every time.

EDIT: The alpha build only gives an error if there is an active inking path present on the canvas and you try to draw another, or you press delete. This only happens on a Motion LE1700 Win7 32bit machine. Does not occur on the ATIV Win8.1 64Bit machine. Inking pen brush rendering speed seems to be comparable between all windows versions, is faster on the alpha build vs. the beta, with the alpha running on a slower 32bit machine and beta running on a 64bit machine, 3-4x more powerful. All windows versions are muuuuuch slower than Linux at rendering inking pen brush strokes.

Turning off automated back-ups showed no improvement.

Running Input Device test, Motion read approx. 135, with 1350 events suppressed when drawing circles for approx. 5 seconds in both alpha and beta builds.

Turning off 'no double buffering' in the debug area of the beta build seemed to have an effect. There is still lag, but it seemed, and I stress "seemed", that it was less sluggish.

These strokes aren't 'made of lines'. They are quite smooth, as expected. They look great.


Redid testing on my old Motion LE1700 Core 2 duo tablet. Video linked below. 4 quick videos.

Test run using only the first 4 pencils of Set#1, quick brushes usually used for sketching.. In this test I try to draw a squiggle and quickly reach for the brush palette to select another brush before the rendering of the stroke is complete. This creates a single stroke made by two different brushes. I did this to show the varying degrees of brush delay in each version, whether one version is faster than the other. Tumagonx's alpha build wins. scons enable_openmp=no seems to be next in line. Tried running tests on a Win7 VirtualBox VM using an old Wacom Graphite Drawing tablet. Problems. Though I can draw well with other drawing apps, like ArtRage and Photoshop, on this VM, for some reason, MyPaint wasn't having it. Once the cursor moved over the canvas there was stuttered movement and I could barely draw a line. Gave up.

scons enable_openmp=no
https://www.dropbox.com/s/24f8o629uecxv5c/20150806_222633.mp4?dl=0

scons debug=yes
https://www.dropbox.com/s/v6ahbma6wnwzgj6/20150806_223856.mp4?dl=0

1.2.0-beta.0+gitexport.adc9031
https://www.dropbox.com/s/np7ltrd3649ggx2/20150806_224108.mp4?dl=0

1.2.0-alpha.20150605+git.4e8a6b5
https://www.dropbox.com/s/usqyzs8y5q7xjre/20150806_224240.mp4?dl=0

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 8, 2015

@achadwick @tumagonx

Based on the inking pen test I mentioned in my most recent (edited) post, it would seem as if the issue we are dealing with is not related to input. What I did was draw lines of near identical form on each machine, one running the alpha build, the other the beta. With these lines drawn and the inking paths active, I changed the brush and observed the time each new stroke took to render. The Alpha is always renders faster, even when run on a much slower machine. Since the stroke is already drawn, I'd argue that the problem cannot be due to the input process.

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Aug 8, 2015

I can't reproduce this with UC-Logic tablet, GTK 3.16.6 against current git. IMO it's virtually the same as using GTK 3.14.13. Though I wouldn't call it responsive whatsoever. When I test beta from github, indeed there is difference.

Hardware: Pentium G2020 2.9 Ghz / 8GB RAM

So far the differences:

  • gcc compiler optimization -O3 vs -Os
  • python mingw vs official
  • winpthreads from latest git vs from 3.2.0
  • numpy: blas vs no blas

Regarding GCC opt. In my experience -O3 is unstable, apps may appear to run normally but tend to crash on strenuous condition, performance mostly around -O2 or worse (if backfired).

@AnomalousG

This comment has been minimized.

Copy link

AnomalousG commented Aug 8, 2015

@achadwick @tumagonx
UPDATE: Just upgraded my ATIV 700t to Windows 10 64Bit. All builds are now working fine. The inking experiment I ran now runs much faster with both 64Bit alpha and beta builds, as well. As a matter of fact, I mentioned that the Linux build rendered inking strokes very fast. Now, with Win 10, the inking strokes of both beta and alpha builds render just as fast as the Linux build, much faster than it did in the alpha build on Win 8; and that was the properly functioning build there.

Let me say, so far, Windows 10 be da shit!! For those who cannot upgrade to win 10 for whatever reason, the beta build problem persists, as it does on my Motion LE1700.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Aug 8, 2015

I'd love some side-by-side graphical comparisons of call graph hot spots for laggy vs. non-laggy builds. We have one already that works for Linux: our cProfile→gprof2dot→graphviz visualizer. See the gprof2dot page for example output.

Unfortunately that's going to need the code you see at

def start_profiling_cb(self, action):
to be ported to Windows (BTW this is good stuff for debugging if "Start/Stop Profiling..." is assigned to a simple free key like F9).

  • cProfile is a built-in Python module.
  • gprof2dot could be included in MyPaint. I think the licenses are compatible.
  • It should probably just write files to a portable tempfile location, not use a pipeline.
  • Fewer subprocess calls, more Python.
  • Online ".dot" renderers exist now: https://mdaines.github.io/viz.js/form.html http://stamm-wilbrandt.de/GraphvizFiddle/. Perhaps what we need is just a POST away these days?

Any love for this approach?

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Jan 1, 2016

@tumagonx That's great news, and I'll be sure to leave enough time. Hope the templating stuff in the .iss.in file is easy to understand, but IIRC:

  • @BITS@: 32 or 64.
  • @VERSION@: the formal version number. Looks like 1.2.0-beta.4 for beta releases, 1.2.0 for the upcoming final release.
  • @OUTPUTBASENAME@: expands to mypaint-w64-1.2.0-beta.4-setup for what I've been doing.

It expects a few support scripts and a particular layout, so I guess you'll be tweaking it anyway.

If the install location is the same (DefaultDirName={pf@BITS@}\MyPaintc:\Windows\Program Files\MyPaint), Inno installers seem smart about overwriting/updating old Innosetup-made installations. I can make future testing releases install somewhere different by default if you want to claim a particular prefix.

I'm cool with GTK 3.14.x too: after all, Ubuntu "Trusty" (14.04 LTS) still uses GTK 3.10.8! I really don't like the autohide scrollbars in newer GTKs. They're fine for touchscreen, but hard to hit accurately with a stylus. Also they're a pain for layouts cluttered with clickable things at the edges, like our previous design for the layers panel.

@DarkDragon83

This comment has been minimized.

Copy link

DarkDragon83 commented Jan 12, 2016

Hey Guys,

i have the same Problems as mentioned here (cant set up my wacom controles and have a huge brush delay)
Mentioned it here:
#561

Iam running windows 7

This was referenced Jan 15, 2016

@Nunuvin

This comment has been minimized.

Copy link

Nunuvin commented Jan 17, 2016

Have similar problem. There is a significant input lag when I use my tablet while my mouse is fine. Solution which worked for me was going into shortcut settings and disabling desktop composition. My version is 1.2.0

@tumagonx

This comment has been minimized.

Copy link
Contributor

tumagonx commented Jan 17, 2016

@Nunuvin Desktop compositing support introduced by gtk 3.18 and
official mypaint 1.2.0 will use gtk 3.14. But official binary haven't
approved/uploaded to github yet. So, which 1.2.0 version did you
meant? (as shown in "about" dialog).

On 1/17/16, Nunuvin notifications@github.com wrote:

Have similar problem. There is a significant input lag when I use my tablet
while my mouse is fine. Solution which worked for me was going into shortcut
settings and disabling desktop composition. My version is 1.2.0


Reply to this email directly or view it on GitHub:
#390 (comment)

!tuma

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Jan 17, 2016

@Nunuvin Which version is this? Sounds like this could be a useful workaround for developer releases which bundle a more recent GTK. At least, it could make future alphas or betas usable by more people.

Any negative consequences for the user from doing this?

@Nunuvin

This comment has been minimized.

Copy link

Nunuvin commented Apr 26, 2016

@achadwick @tumagonx Sorry I did not check github in a while. It was 1.2.0 beta 4. Hope this helps.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented May 11, 2016

Q: Does changing the background make any difference?

I just got an interesting bit of feedback from #678, which is also a Windows lag bug reported against a recent prerelease. Quoting the reporter:

the background dialog, with certain backgrounds ringed as "these are fast"

People encountering this bug may like to try switching to a different background. Though I suspect it may not actually change anything, I recall seeing lag with the default beige background (top right in the image) from earlier.

@AnTi-ArT

This comment has been minimized.

Copy link

AnTi-ArT commented May 16, 2016

phew, long read...

I have the same problem for about the same time... And I have an additional (but useless) piece of information: For me (Win10 64, Cintiq Companion 2 TabletPC) the problem did not occur with Wacom driver 6.3.12, everything above had the lag so far. Sadly I was not smart enough to save a backup of the driver's installer. Additionally it seems like people with other wacom drivers (Feel It) have the lag issue too. I did test the wacom drivers a couple of times, also on my Win7 work desktop PC with an intuos tablet - as far as I remember it had the same driver as my Cintiq. Now I have driver 6.3.15-3 and still, the latest builds of mypaint have the lag.

However:

  • Changing the BG does indeed reduce the lag a little bit.
  • Changing Power mode to High Performance seems to fix the issue for me, too. No noticeable lag! I can work with that :D

Just noticed that there is a new wacom driver on the US website. Testing with myPaint 1.2.1-beta.1:

  • No wacom drivers installed (so no pen): No lag with mouse / touch in high performance and balanced power modes. However circles sometimes have a straight segment.
  • Vanilla wacom driver 6.3.16-2 with balanced & high performance, no background apps: no lag (except for normal low performance with heavy brushes).
  • The same with my usual background stuff: There it is again! And only in balanced power mode. Running stuff: Chrome, Explorer, Hangouts, f.lux, google drive, google photos, creative cloud, oneDrive, virus protection...
  • Tested with my good old wacom settings loaded, same results.

btw I had to go back to 6.3.15, since the .16 drivers &?@# up touch input. Well done, wacom...

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented May 16, 2016

Whoops, was just bout to ask what version that was. So this problem is gone in Wacom driver 6.3.16-2, in High Performance power mode for all combinations of background apps?

@AnTi-ArT

This comment has been minimized.

Copy link

AnTi-ArT commented May 17, 2016

I did not test all apps in isolation. Chrome is for sure the biggest resource thief. If I load up lots of stuff it starts to lag in High performance, too (of course). But slowly, not like the buggy lag.

Nah, the issue is still present in .16 when using the balanced power mode. It's pretty much the same behaviour as .15 (except that .16 itself is buggy and I had to revert anyway). However I never tested the power settings with older wacom drivers. I just know that I reverted back to .12 a couple of times last year and this fixed the problem on my tablet and on the work PC.

By the way, I did finally go through the build process on Windows: Right now I am in balanced power, have a lot of crap running in the background and 1.3.0-alpha+git.1fc6f4c (Python 2.7.11, GTK 3.20.4, GdkPixbuf 2.35.1, Cairo 1.15.2, GLib 2.48.0) still has NO noticeable lag! Even complex brushes run smoothly. 👍
[Edit] Well, after a restart I got the lag again in 1.3.0 - But at least it appears only occasionally. I draw for a while then suddenly the line slows down, stays behind and catches back up with the pen, true to the drawn path (no straight shortcuts).

@Robsoie

This comment has been minimized.

Copy link

Robsoie commented May 19, 2016

Hello,

I had just noticed that 1.2.0 was officially released out of the beta status in january and that tumagonx built it using the same GTK version (GTK (and GDK) 3.14) that he used in his builds on his blog (that was slightly older than the GTK from the beta 1.2.0 serie)

So i gave a try to the 1.2.0 win32 installer to see if this change of GTK would have done something related to the very laggy problem i had with the 1.2.0 beta serie and noticed when painting with my mouse that i had no more any of the lags i observed with the 1.2.0 beta versions.
In fact brush strokes are working as immediately as they were in tumagonx builds, making it a pleasure to use MyPaint again.

[EDIT: corrected MyPaint version numbers -- achadwick]

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Jan 23, 2017

Alright. This is the biggie.

MyPaint v1.2.1 has been released. Please can everyone try it out and see if this bug is still happening?

Some news for the new release: I'd love it if people could check for the lagginess in the GTK3-Demo we now bundle as of v1.2.1. I made the start menu shortcut for it open the "Event Axes" (Touch and Drawing Tablets) demo because that acts as a pressure/tilt tester, but if you close that and run the "Drawing Area" demo instead at fullscreen, you get another little scribble pad. If you get lag, please try that thing out in a maximized window, and tell me whether or not it happens still.

One big thing I noticed testing all the tablet stuff that went into its GTK lib: the Wacom "professional" drivers for my Intuos5 are a lot more responsive than the ones Huion made for my H610PRO. The Wacom experience (on a slowish, 2-core Windows 7 machine) is similar to what you get in Linux X11. The Huion experience is usable, but feels noticeably slower, laggier, and notchier for scribble painting. The only difference is whatever the manufacturer's Wintab DLL's doing, so I wonder if it's flooding the current window with more windowing messages or something.

(The H610PRO is a great little tablet under Linux, comparable to to the Wacom. In my experience.)

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Feb 3, 2017

We need feedback on this. Is the lag still happening with the latest release?

@Anvilfoot

This comment has been minimized.

Copy link

Anvilfoot commented Feb 3, 2017

I've installed and run Mypaint 1.2.1-1 32 bit. I tried drawing generally, full screen and not, as well as the "Drawing Area" demo.

Under no circumstances have I noticed lagginess, at all. I have seen multi-second lag in the past, as well as just perceptible slowness on my system. All of that seems to be gone now, in fact MyPaint is now as responsive as any drawing program I've used! Bravo!

I'm running MyPaint on an Asus Vivotab Note 8 (Baytrail tablet w/ Wacom digitizer). OS is Win8.1, and am using Wacom Feel driver v.7.3.2-12.

@MR4Y

This comment has been minimized.

Copy link

MR4Y commented Sep 10, 2017

Problem still exists for me...But doesn't happen on 1.0.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Sep 10, 2017

Please can everyone still experiencing this with $RANDOM_OLD_BUILD please try the latest beta build? Newer libs may fix bugs.

It's at https://ci.appveyor.com/project/achadwick/mypaint/branch/master (click on either the MINGW64 or the MINGW32 job, your call, then click on the "ARTIFACTS" tab on the right, and download the -installer.exe.

Let us know how it goes.

When you report back, please include the full version including all the library versions from the about box. You can cut and paste from it.

@achadwick

This comment has been minimized.

Copy link
Member

achadwick commented Sep 10, 2017

I've never been able to reproduce this one myself even on a slow old Win7 dual-core laptop. Really understanding it is going to take someone who can a) reproduce it, and b) has the skills to go looking for a cause. Hopefully the tools you all need are out there though (MSYS2 source PKGBUILD, our bundled gtk3-demo, profiler stuff in the debug menu...)!

@AtsusaKaneytza

This comment has been minimized.

Copy link

AtsusaKaneytza commented Oct 28, 2017

I'm experiencing laggy strokes as well. I searched the repo for similar problems and figure I should report my problem here:

Specs:
Microsoft Surface 3
RAM: 2GB
Surface 3 Pen + Wintab Drivers (thanks for the pressure fix btw!)
OS: Windows 10, 64-bit
MyPaint 32-bit: 1.3.0-alpha+git.0b19fce4
(Python 2.7.14, GTK 3.22.24, GdkPixbuf 2.36.11, Cairo 1.15.6, GLib 2.54.1)

I just tested my other drawing software and they don't lag like MyPaint is doing in this version. Considering how lovely MyPaint is for its responsiveness, I do find this a bit strange.
I'll also try testing this build on my Acer laptop and Yiynova tablet and let you know if similar is happening.

@AtsusaKaneytza

This comment has been minimized.

Copy link

AtsusaKaneytza commented Oct 28, 2017

Tried testing the 64-bit version as well, and it seems to have around the same amount of lag.
Software: MyPaint 1.3.0-alpha+git.0b19fce4
(Python 2.7.14, GTK 3.22.24, GdkPixbuf 2.36.11, Cairo 1.15.6, GLib 2.54.1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment