Bug 427335 - Render brush cursor separately from the canvas pixels ?
Summary: Render brush cursor separately from the canvas pixels ?
Status: RESOLVED NOT A BUG
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 4.4.0-beta2
Platform: unspecified Microsoft Windows
: NOR wishlist
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-04 19:12 UTC by stephen
Modified: 2020-10-14 03:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stephen 2020-10-04 19:12:51 UTC
SUMMARY
Greetings guys.
Can you please separate the brush cursor's render process
from that of the Canvas' ? There's a weird and slight stutter/delay just after the end of each stroke while painting. The issue is even more obvious with Instant Preview mode active.

STEPS TO REPRODUCE
1. with a pixel engine brush selected, paint multiple strokes like if
you wanted to do hatching lines. Instant preview is inactive.
2. repeat step 1 by painting as fast as you can and see if the brush cursor doesn't jump to catch up(might be frame drop at the end of each stroke, I don't know)
3. repeat step 1 with but this time with Instant Preview active.

OBSERVED RESULTS
At the end of each Stroke, the brush cursor stops moving or freezes for a brief amount of time then jumps to its correct position. With instant preview inactive, the impact is dampened. But with Instant preview active, it's just obvious.

Tested on a Krita plus stable build : version 4.4.1 alpha(git b20cb06).

OS : Windows 10 1909
Comment 1 Halla Rempt 2020-10-05 07:45:23 UTC
Sorry, but, no, that cannot be done.
Comment 2 stephen 2020-10-05 16:33:04 UTC
(In reply to Boudewijn Rempt from comment #1)
> Sorry, but, no, that cannot be done.

If that can not be done, then how did you manage to implement
the brush Cursor Shape which moves effectively in real time according to user input ?
It never lags, it's always responsive, and we need those pros for the Outline Shape as well. But, do you, at least, understand the issue ? It's what matter the most; if you do, then it's good and we can expect for change sooner or later.
Comment 3 Halla Rempt 2020-10-05 16:41:21 UTC
Of course I understand the issue. I first ran into this in 2004. Cursors are drawn by the display manager of the window system. That system cannot be used to draw the brush outline.

Btw, do not change the status of bugs: only developers should do that.
Comment 4 stephen 2020-10-06 00:02:39 UTC
(In reply to Boudewijn Rempt from comment #3)
> Of course I understand the issue. I first ran into this in 2004. Cursors are
> drawn by the display manager of the window system. That system cannot be
> used to draw the brush outline.
> 
> Btw, do not change the status of bugs: only developers should do that.

OK...
But there's got to be a way.
Maybe this would help you in the future. 
https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor-image
Comment 5 stephen 2020-10-14 03:08:40 UTC
(In reply to stephen from comment #4)
> (In reply to Boudewijn Rempt from comment #3)
> > Of course I understand the issue. I first ran into this in 2004. Cursors are
> > drawn by the display manager of the window system. That system cannot be
> > used to draw the brush outline.
> > 
> > Btw, do not change the status of bugs: only developers should do that.
> 
> OK...
> But there's got to be a way.
> Maybe this would help you in the future. 
> https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor-
> image

Alright. It turns out, things are much smoother with OpenGL renderer active rather than DX11 ANGLE. And so, brush cursor spped might not be an issue anymore.
However the Black/White color change option is still awaited, guys.