Hello! This is my first time on the forums here, so I apologize if this is something already addressed in another topic. If this happens to be the case, please let me know so I can go to the topic corresponding to this issue.

I work on a monorpice tablet on windows 10, which had never been a problem for Krita before and had worked splendidly up until I got the 3.0 update.

When I use the selection tool (any selection tool, really), what's selected and the path I'm drawing to be selected are off by about ten pixels or so. This interferes with the transformation tool as well. When I rest my cursor on the anchor, I get the rotation icon and it acts accordingly, but a little above and to the left of the anchor's box.

This seems to only be a problem when I use my tablet, as my mouse doesn't seem to have this issue. I'm unsure how to fix it in preferences and I'm completely clueless with coding.

It's nothing huge, I suppose. It just messes with my work flow and I'd like to be able to get back to learning the software properly.

Thank you for reading, and thank you in advance for your helping me.

I can confirm this! I also have a Monoprice tablet and have this same exact issue.

The really odd thing is... that when I try to record a video of this occurrence through OBS Studio, the problem is gone... meaning, the pixel offset is no longer present.

At first I thought it was because I had to switch OpenGL off to ensure that OBS Studio could pick up the Canvas in Krita, but the pixel offset problem persists both with OpenGL on and off if OBS Studio is not running.

Also, while OBS Studio is running, my pressure sensitivity for my brush is lost.

I think I had a similar problem when I ran Krita 2.9 to migrate my settings to Krita 3.0 - the brush sensitivity issue to be specific.. I'd have to test if the pixel offset for Selection and Transform are corrected if Krita 2.9 is open. Edit: The pixel offset is negated if I have Krita 2.9 and Krita 3.0 open at the same time, but once again I lose pressure sensitivity in my brushes.

Long story short, the pixel offset problem persists during specific cases... maybe when the canvas is not being monitored by another program. If the canvas is monitored by another program, the pixel offset issue is corrected, but pressure sensitivity in the brush is lost [for this tablet model at least]

Krita version: 3.0 (git f0cbffc)
Link to the tablet model: http://www.monoprice.com/Product?c_id=1 ... 1&format=2
Link to tablet driver: http://www.uc-logic.com/index.php?lang= ... ort&cid=17 1st option, seeing as I'm on Windows 7
I'm on Windows 7, 64bit, Service Pack 1

If the problem goes away and you lose pressure sensitivity when using OBS that means that OBS disables your tablet's driver, probably because the OBS people have found that it gives problems. Which is not strange: Monoprice is one of the tablets that have really, really badly written drivers. There are worse (https://krita.org/item/anatomy-of-a-bug-fix/), but that doesn't make Monoprice good.

As for the pixel offset problem: I think we can reproduce that with the piece-of-crap Trust tablet we bought to fix the above mentioned bug. We might find another workaround for that bug in the driver. And before you start telling me "but it works in Photoshop so the tablet is fine" -- that's not relevant. The expletive-deleted programmers who write the wintab driver for these tablets only test with photoshop. They don't care about the standard, don't care about the documentation, the hack around until it works with photoshop and then consider their job done.

So, of course you don't have that problem with your mouse and you don't have the problem with something disables your tablet driver because then the whole tablet driver doesn't come into play.

boudewijn wrote:If the problem goes away and you lose pressure sensitivity when using OBS that means that OBS disables your tablet's driver, probably because the OBS people have found that it gives problems. Which is not strange: Monoprice is one of the tablets that have really, really badly written drivers. There are worse (https://krita.org/item/anatomy-of-a-bug-fix/), but that doesn't make Monoprice good.

As for the pixel offset problem: I think we can reproduce that with the piece-of-crap Trust tablet we bought to fix the above mentioned bug. We might find another workaround for that bug in the driver. And before you start telling me "but it works in Photoshop so the tablet is fine" -- that's not relevant. The expletive-deleted programmers who write the wintab driver for these tablets only test with photoshop. They don't care about the standard, don't care about the documentation, the hack around until it works with photoshop and then consider their job done.

So, of course you don't have that problem with your mouse and you don't have the problem with something disables your tablet driver because then the whole tablet driver doesn't come into play.

Thank you for the explanation :3

And yes I agree... Monoprice has bad drivers. It's one of the only problems I have with this device, but otherwise its an amazing product.

Hopefully I'm not aggravating you in any way. Just wanted to make sure you got some more information to work on :3

We're all very grateful for the work you guys do!! :3

However, I am able to stream with no pressure sensitivity issues when I use Krita 2.9 animation editor beta build and OBS Studio, so long as I have OpenGL disabled.

https://youtu.be/f8AiWxx-ooE

https://youtu.be/OomSi1j16Fg

Why would OBS Studio choose to disable the tablet driver if Krita 3.0 is open, but not for Krita 2.9? Is it possible that the tablet driver is being disabled by Krita 3.0 somehow if another application is interacting with it either directly or indirectly?

Edit: Sorry, I'll move this to the more relevant topic*

I was seeing this same issue on Windows 10, using a Wacom Intuos with the latest drivers, so it's not just Monoprice tablets that have the issue.

Weird thing is that the cursor lines up perfectly for brushes. It's only the selection tools that demonstrate the offset...well, and the Tablet Tester, which showed the same offset.

I was able to fix it in the "Choose screen resolution" dialog (the one you get by holding shift after startup, before tapping your stylus for the first time). It had the correct resolution and my brushes lined up correctly, so I'd have assumed it was okay. I decided to play with it anyway, since the Tablet Tester showed the problem, too. Adjusting the "Y offset" setting eliminated the problem and, thankfully, did so without screwing up my brushes, so now everything is working correctly.