Bug 360588

Summary: Brush is smoother and less laggy with OpenGL turned off
Product: [Applications] krita Reporter: Chris Jones <chrjs>
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: normal CC: dimula73, halla, osxyz
Priority: NOR Keywords: regression
Version: 3.0 Alpha   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Attachments: Stroke opacity glitches
Brush with spacing controlled by speed

Description Chris Jones 2016-03-16 01:04:14 UTC
Brushes are choppier and the stroke lags more when OpenGL is turned on.  The difference is only slight, but enough for it to be preferable to work with OpenGL turned off.

Tested in krita3-prealpha3-de0d43d on Surface Pro 4 (i5 8GB) and desktop PC (Quad core with NVIDIA GeForce 9600 GT), both on Windows 10.  More apparent on the SP4 than the desktop.

Reproducible: Always

Steps to Reproduce:
1.  Create a 7000 x 4500 image
2.  Select an ink brush and draw scribbles
3.  Compare with OpenGL turned off
Comment 1 Halla Rempt 2016-03-22 15:17:20 UTC
Hi Chris,

What is the colorspace/channel depth of your image? And which preset are you using exactly? I've tried on my SP3, but both opengl and cpu canvas are smooth and curves come out perfectly curved (even on Linux, when running with a performance tuner like valgrind, the curves are perfectly smooth -- we're not skipping any events any more).
Comment 2 Chris Jones 2016-03-23 00:30:34 UTC
Hi Boud,

This is with RGB 8 or 16 bit using the default colour profile.  Occasionally the problem is more pronounced with 16 bit (I haven't figured out why), so I'd suggest testing with 16 bit.  It happens with any of the presets - Fill Circle is probably a good example.

To clarify, the quality of the curve isn't affected as such, it's just the way the strokes appear to be laid down, as if the frame-rate is reduced.

Incidentally, turning OpenGL on and off a few times (closing the preferences panel in-between) usually results in a crash.
Comment 3 Halla Rempt 2016-04-15 06:35:01 UTC
That sounds like an additional initialization problem :-(
Comment 4 Chris Jones 2016-04-19 12:41:16 UTC
Created attachment 98464 [details]
Stroke opacity glitches

I've noticed now that this is having an effect on certain brushes in the form of glitches in stroke opacity (see attachment) on the SP4.  Only turning off OpenGL or using the Dynamic Brush Tool seems to smooth out this problem.  I haven't been able to reproduce this issue on the desktop as yet.

Also when creating a lot of strokes with OpenGL on and then clearing the canvas by going back to <empty> at the start of the undo history, blocks of the canvas are not refreshed until I draw over those parts of the canvas and hit undo or clear again.
Comment 5 Chris Jones 2016-04-19 12:52:38 UTC
Also, the choppiness and lag is very noticeable on a 7000 x 4000 image when the whole canvas is in view, and the blocks of stroke pop into view behind the pen as it moves across parts of the canvas that have not been drawn on yet.  This does not occur when OpenGL is off.
Comment 6 Chris Jones 2016-04-19 13:12:34 UTC
Ok, it looks like the same opacity glitch problem happens on the desktop as well.
Comment 7 Halla Rempt 2016-04-19 14:35:46 UTC
Does it matter whether you have instant preview on or not?
Comment 8 Chris Jones 2016-04-20 00:53:11 UTC
Created attachment 98470 [details]
Brush with spacing controlled by speed

Same results whether Instant Preview is on or off.

I've attached another image that demonstrates this issue more clearly, as well as the brush used to create it.  I've set the spacing to be controlled by the speed of the brush.  The Dynamic Brush Tool doesn't eliminate these spacing fluctuations.

I'm not sure whether this particular issue is related to the other ones above or not, but it is related to OpenGL.
Comment 9 eliotJ 2016-05-27 09:48:42 UTC
It looks like this bug is related to this one: https://bugs.kde.org/show_bug.cgi?id=362445
Comment 10 Dmitry Kazakov 2017-04-28 17:05:26 UTC

*** This bug has been marked as a duplicate of bug 359171 ***