Skip to content
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

Interrupted brush stroke issues with tablet and 1.2 #1683

Closed
artisteacher opened this issue Dec 13, 2017 · 19 comments · Fixed by #1753
Closed

Interrupted brush stroke issues with tablet and 1.2 #1683

artisteacher opened this issue Dec 13, 2017 · 19 comments · Fixed by #1753

Comments

@artisteacher
Copy link
Contributor

artisteacher commented Dec 13, 2017

With the new tablet fix for OS X in 1.2, interrupted brush strokes still seem to have undesirable results. On a vector level, if the brush stroke is interrupted by an accidental button press or auto-save, the unfinished stroke is unable to be finished. After starting a new stroke, the incomplete stroke disappears and is replaced by the new stroke. On other level types, the interrupted stroke behaves like a completed stroke and remains visible. It would be better for auto-save and additional stylus input to be delayed until the brush stroke is finished. In the meantime, the accidental input can be minimized by being careful with the stylus grip (though that does not help the auto-save problem).

Possibly related, the greyed out/inaccessible menu problem #618 seems to be more of an issue than it’s been in a while.

Edit: it seems like auto-save does delay until the stroke is finished when using the trackpad (and mouse?) instead of a tablet. If auto-save interrupting something in progress is what actually triggers the inaccessible menu, delaying autosave until the stroke or etc. is complete could resolve the issue.

@tushantin
Copy link

I'm having the same issue, but in a different fashion (on Linux). Apparently, Auto-save isn't required for the stroke-disappearing act to happen. It just happens either way when using the tablet, but doesn't when using the mouse.

I've described this phenomenon here, which it may be related to, where b4zz4 has also posted a GIF to demonstrate what we mean: #1371 (comment)

@b4zz4
Copy link

b4zz4 commented Dec 19, 2017

Linux Mint 18 (Sarah)
Wacom Intuos Draw CTL-490

Bus 002 Device 004: ID 056a:033b Wacom Co., Ltd

@Orphanlast
Copy link

I think everyone, regardless of platform has been experiencing that. I'm just accustomed to assuming I'll have to redo that stroke or whatever after the auto save or whatever.

@artisteacher
Copy link
Contributor Author

artisteacher commented Dec 19, 2017

@b4zz4, that’s exactly what I’m getting. @tushantin I can force the behavior by deliberately pressing on a shortcut or stylus button while drawing a vector stroke. Is it possible that you are accidentally pressing one of the stylus buttons (which is really easy to do on a wacom stylus)?

@Orphanlast, hopefully that means this can be resolved sooner rather than later. It’s not a huge deal but makes working with a tablet feel less polished than other programs. Honestly the greyed out menu that often occurs at the same time in OS X (which makes it seem related) is a much bigger inconvenience. Redrawing a line is way better than restarting the program.

@morevnaproject
Copy link
Contributor

@tushantin Just in case if you missed this: Is it possible that you are accidentally pressing one of the stylus buttons?

The problem shown by @b4zz4 and @tushantin seems not to be related with autosave and looks more like #1704

@b4zz4
Copy link

b4zz4 commented Dec 25, 2017 via email

@morevnaproject
Copy link
Contributor

@b4zz4 Please check if you have the same problem with this special version 1.1.3.9 - https://sourceforge.net/projects/opentoonz-morevna-edition/files/stable/1.1.3.9/
Please post your result to #1704.

@morevnaproject
Copy link
Contributor

@Orphanlast I am waiting for your feedback about 1.1.3.9 (my last mail) ^__^

@tushantin
Copy link

tushantin commented Dec 26, 2017

@morevnaproject No it seemed to be related, but different issue for me, because I neither needed to click buttons nor enable autosave for lines to disappear — which seemed to be fixed in the build you shared last time. Although, I did also have that button-click / disappear problem.

Even more interestingly, the build that you shared just recently, related to the middle-click testing, seems to no longer erase the lines even IF I middle-click or right-click while drawing. Middle-click seems to just end the stroke and allow the line to exist, while right-click makes the stroke assume that the drawing is still continuing, so that you can continue where you left off.

@morevnaproject
Copy link
Contributor

@tushantin @b4zz4 Please check the build I have posted here - #1704 (comment)

@tushantin
Copy link

tushantin commented Dec 27, 2017

@morevnaproject The build you provided recently seems to give me the same results as the previous special build: no stroke-disappearing issue, just that the stroke pauses with middle-click until you resume drawing again (which probably isn't a big deal, at least for me, so it's a question of whether that bit of interruption is intended to be there).

Hopefully it works for @b4zz4 too in this case.

@morevnaproject
Copy link
Contributor

Fixed in Morevna Edition 1.2.0.2 by reverting changes of #1659.

Official OpenToonz still affected. See relevant comment - #1659 (comment)

@artisteacher
Copy link
Contributor Author

@morevnaproject, thank you. However the problem with reverting back to the previous behavior is that the original tablet glitch in OS X where the brush randomly generated strokes on its own without any deliberate input from the stylus will be a problem again. It would be so helpful to actually have all of the tablet issues (#1058 #618 #756 & etc.) resolved so that tablets could work smoothly across all platforms.

@jpturcotte
Copy link
Contributor

And there is a bounty still open!

@morevnaproject
Copy link
Contributor

@artisteacher You right. But tablet fix for OSX breaks behavior for two other platforms (Windows and Linux). Of course it would be good to have real solution, but it surely takes time. So we have decided to roll it back, until it get resolved in favor to have working version on Windows and Linux.

@jpturcotte
Copy link
Contributor

@morevnaproject Can't you make a special build for macOS users?

@morevnaproject
Copy link
Contributor

@jpturcotte This is technically problematic to maintain a separate build within our limited resources. We will need to do double work for every release. Let's wait for the fix.

@jpturcotte
Copy link
Contributor

I understand, although we will have to wait for a long time since nobody is working on this.

@shun-iwasawa
Copy link
Member

I tested on Windows and found that there is a case that Qt recognizes tablet is touching with pressure = 0 .

In the previous modification I added a process to cancel the stroke in such case ( here ) in order to prevent unwanted stroke being drawn while hovering the pen. This workaround may be a probable cause of this issue, at least on Windows.

Instead of cancelling a stroke, I'll try inserting a process for ending the stroke just like releasing the pen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants