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

Huion/Windows Ink Incompatabilities. #2882

Closed
ccioanca opened this issue Aug 11, 2021 · 3 comments
Closed

Huion/Windows Ink Incompatabilities. #2882

ccioanca opened this issue Aug 11, 2021 · 3 comments

Comments

@ccioanca
Copy link

Issue

It seems that theres a disconnect somewhere in the Aseprite/Windows Ink/Huion Tablet or Software pipeline.
The issue is hard to explain. So I'll try to use some diagrams to my advantage.

In short, the issue is this:

When Windows Ink is enabled in the Huion Software, scroll-to-zoom does not work as expected. The scroll uses the last mouse position as the point of reference when zooming, rather than the current cursor/pen position. Pen pressure works as expected.

When Windows Ink is disabled in the Huion Software, scroll-to-zoom works as expected, but pen pressure no longer works.

A little more explanation:

image

In the image above, if the user moves the mouse to where the cursor icon is (top right), but then the user switches to the pen stylus and draws the pink circle, and tries to zoom the canvas at this position by using scroll-to-zoom; the expected behavior would be to zoom into the current position of the stylus. What actually happens is that Aseprite remembers the last position of the mouse, and tries to zoom there instead (top right, where the mouse icon is). There is no indication that this is what the outcome would be, and sometimes this leads to really frustrating zooming instances, since the user wont remember where their last mouse position was.

I can also rule out any interaction between Aseprite and Wintab since I've tried toggling things in every configuration I could think of, and nothing seems to have fixed it. Wintab is off by default, since I set Aseprite to use Windows Ink.

I've only been able to find one reference to this problem, and it was a subcomment to a separate issue:
https://community.aseprite.org/t/huion-kamvas-tablet-only-draws-single-pixels/5695/13

I don't believe this person's issue was ever fixed. It seems that this has been an issue since at least v1.2.19. Hopefully I was able to give more information.

I can attest that this has been a problem for a while. I usually don't use the pen pressure feature in aseprite, so this is generally not a problem for me, but if I'm switching between Aseprite and another program that I do want to use pen pressure for, like Photoshop, I have to continually toggle the Windows Ink box in the Huion Software:
image

I can add more information as needed, or record a video showing the issue and symptoms of toggling the Windows Ink checkbox on and off.

Versions and System Information:

  • Aseprite version: v1.3-beta5-x64
  • Tablet: Huion Inspiroy Q11K V2 (Also tested on HUION KAMVAS Pro 13 GT-133)
  • Tablet Firmware: T185_180709 (Inspiroy Q11K V2)
  • Huion Software Version: b15.3.19.174 (But the issue persisted in earlier versions as well)
  • System: Windows 10
@ccioanca
Copy link
Author

Of course, right after I post this, I find that an issue already exists, and is planned for 1.13 beta 6:
#2783

Closing this issue as it's a duplicate.

@dacap
Copy link
Member

dacap commented Aug 11, 2021

Hi @ccioanca, no problem about reporting this issue. It's good to know that more users are affected with this so more feedback we can be get from it the better.

I've tried to fix this but there is a strange issue on Windows where the mouse (or trackpad) position is reported from time to time (e.g. each one second) to the application, which overwrites the last position of the pen. If you move the pen while zooming that shouldn't be a problem, but even in that case, sometimes you could experience a random problem (e.g. if the zoom is just executed when we receive the random "mouse move" event from the trackpad position).

It looks like the random or continuous WM_MOUSEMOVE messages is a known thing by Microsoft but they never fixed it or don't have plans to do it:

https://devblogs.microsoft.com/oldnewthing/20031001-00/?p=42343

I'll try to create a bug report or something.

@ccioanca
Copy link
Author

@dacap Ah that's super frustrating when something is out of your control like that. I hope a magic fix comes along! :)

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

No branches or pull requests

2 participants