[krita] [Bug 370237] Strokes are delayed ~1.5 seconds after the previous stroke

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370237

--- Comment #6 from Chris Jones  ---
I forgot to add that this problem resurfaced in the first 3.1 beta (3.0.99.90),
so I'm still using 3.0-9e17aff since that's the most recent build that doesn't
exhibit the problem.  I don't recall when it initially cropped up (it might
have been in the switch from 2.9 to 3.0) and then was subsequently fixed, but
I'll try and locate those versions if that would help in tracking down the
issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 370237] Strokes are delayed ~1.5 seconds after the previous stroke

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370237

--- Comment #5 from Chris Jones  ---
No stabilizer, only basic smoothing is on, although none of the smoothing
options seem to make any difference.  Also I haven't been able to repeat the
Advanced Colour Selector incident so far.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 370237] Strokes are delayed ~1.5 seconds after the previous stroke

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370237

--- Comment #2 from Chris Jones  ---
Happens whether it's enabled or not.

Strangely, I just opened the Advanced Colour Selector docker, and the problem
went away until I closed it again.  I tried opening it again and the problem
was still there though, so I'm not sure what that was about.  Does that offer
any clues?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 370237] New: Strokes are delayed ~1.5 seconds after the previous stroke

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370237

Bug ID: 370237
   Summary: Strokes are delayed ~1.5 seconds after the previous
stroke
   Product: krita
   Version: 3.0.2 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Brush engine
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

When drawing on a large canvas, the appearance of a stroke is delayed
momentarily every so often.  For me this occurs approximately one and a half
seconds after the previous stroke, and the problem can be sustained by drawing
a new stroke every 1.5 seconds thereafter.

Confirmed in Krita 3.0.1.90, Windows 10 on both an 8 year old desktop and a
Surface Pro 4.

Reproducible: Always

Steps to Reproduce:
1. Create a new 7000 x 4000 image
2. Select any brush and draw a series of short strokes, gradually increasing
the time between strokes until there is a delay.



Note: I think this was either reported or mentioned somewhere in a previous
report, but unfortunately I was unable to locate that report, so apologies if
this is a duplicate.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 365179] New: Crash when nudging a hidden layer

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365179

Bug ID: 365179
   Summary: Crash when nudging a hidden layer
   Product: krita
   Version: 3.0
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

A crash occurs when a hidden layer is nudged using the arrow keys.  This
happens frequently when trying to accurately position a layer while
hiding/unhiding it to check if it's in the right position.

Reproducible: Always

Steps to Reproduce:
1.  Create a new image with 2 layers
2.  Select the move tool and select layer 2
3.  Hide layer 2 and press an arrow key

Actual Results:  
Crash.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363770] Selection outline appears black or green with OpenGL enabled

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363770

--- Comment #6 from Chris Jones  ---
Created attachment 99335
  --> https://bugs.kde.org/attachment.cgi?id=99335=edit
Selections and outlines on SP4 and desktop in 2.9 and 3.0

Here's a screenshot comparison.

I found the line tool preview is also black on the Surface and green on the
desktop, no doubt other tools are affected as well.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363770] Selection outline appears black or green with OpenGL enabled

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363770

--- Comment #4 from Chris Jones  ---
Actually now that you mention it the brush preview outline is indeed also
affected.  On the Surface it's black, on the desktop (which uses an NVidia GPU)
it's green.  So this does look to be related, and not just on AMD cards.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] [WACOM] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #22 from Chris Jones  ---
Created attachment 99307
  --> https://bugs.kde.org/attachment.cgi?id=99307=edit
Stroke start glitches in krita-3.0-da5496d-x64

Hi Dmitry,

Here are videos and logs of both my desktop PC and Surface Pro 4.

An interesting new finding is that the Surface often produces a double-start to
the stroke when OpenGL is enabled, along with a slight hook.  Without OpenGL it
just produces the hook.  I've only noticed this now because normally I'm having
to use the SP4 without OpenGL due to a stuttering issue
(https://bugs.kde.org/show_bug.cgi?id=360588), and it's possible this is
exacerbating the problem and causing the double-strokes.

My desktop also displays similar stuttering when using High Quality filtering
(https://bugs.kde.org/show_bug.cgi?id=331794), but doesn't produce
double-strokes with other scaling modes or with OpenGL off though.

Incidentally I've used CamStudio to record the videos and it's possible you'll
need the CamStudioCodec to view them...  let me know if you have playback
problems and I'll try something else.

Hope that helps!

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363770] Selection outline appears black or green with OpenGL enabled

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363770

--- Comment #1 from Chris Jones  ---
Correction, it appears black instead of *inverse* on the SP4, and green instead
of inverse on my desktop PC (which makes it hard to seen on green backgrounds).

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363770] Selection outline appears black or green with OpenGL enabled

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363770

Chris Jones  changed:

   What|Removed |Added

Summary|Selection outline appears   |Selection outline appears
   |black on Surface Pro 4 with |black or green with OpenGL
   |OpenGL enabled  |enabled

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363770] New: Selection outline appears black on Surface Pro 4 with OpenGL enabled

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363770

Bug ID: 363770
   Summary: Selection outline appears black on Surface Pro 4 with
OpenGL enabled
   Product: krita
   Version: 3.0
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: OpenGL Canvas
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

When using a selection tool, the outline that is drawn before the selection is
closed and turns into marching ants appears black instead of the usual green
when OpenGL is turned on.  This makes it difficult or impossible to see the
selection as it is being drawn onto a dark image.

Surface Pro 4 i5 8GB, Windows 10, Krita 3.0 (git f0cbffc)

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363316] Strokes pause momentarily at regular intervals

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363316

--- Comment #5 from Chris Jones  ---
https://www.dropbox.com/s/iuwcr95vvsrlgvf/stroke_pauses.zip?dl=0

Drawing on layer 1 with any brush should produce the effect.  The original also
had this problem on layer 5 and some of the other layers to a lesser extent,
until I cleared the layers of any imagery.  Does that give any clues?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363316] Strokes pause momentarily at regular intervals

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363316

--- Comment #3 from Chris Jones  ---
No sooner had I posted that comment than the more overt behaviour returned
(typical!), this time when I loaded a slightly larger image with a few more
layers.

SP4:
Image size: 1.6G
Memory used: 1.3G / 4.0G
 image data: 1.2G / 3.9G
 pool: 81.0M / 81.0M
 undo data: 17.5M
Swap used: 17.5M

Desktop:
Image size: 1.6G
Memory used: 1.1G / 4.0G
 image data: 1.1G / 3.9G
 pool: 81.0M / 81.0M
 undo 24M
Swap used: 114.7M

It looks to be always reproducible on that particular image.  Neither 2.9.9 nor
3.0 alpha 1 exhibit this issue with the same image.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363316] Strokes pause momentarily at regular intervals

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363316

--- Comment #2 from Chris Jones  ---
Of course, now that I actually want it to happen, I'm having a hard time
reproducing it (typical!).  I was doing a lot of editing and testing presets at
the time so maybe it was something I was doing related to that that was
triggering it.

It's doing it subtly on the SP4 at the moment though, here are the stats:

Image size: 668.9M
Memory used: 837.1M / 4.0G
 image data: 756.1M / 3.9G
 pool: 81.0M / 81.0M
 undo data: 47.9M
Swap used: 2.1G

I'll report back if the behaviour becomes more overt.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363364] Spacing is inconsistent when controlled by speed

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363364

--- Comment #2 from Chris Jones  ---
Created attachment 99111
  --> https://bugs.kde.org/attachment.cgi?id=99111=edit
Spacing Speed preset

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363364] Spacing is inconsistent when controlled by speed

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363364

--- Comment #1 from Chris Jones  ---
Created attachment 99110
  --> https://bugs.kde.org/attachment.cgi?id=99110=edit
Spacing glitches

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363364] New: Spacing is inconsistent when controlled by speed

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363364

Bug ID: 363364
   Summary: Spacing is inconsistent when controlled by speed
   Product: krita
   Version: 3.0 Release Candidate
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Brush engine
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

When speed is used to control spacing, the spacing is erratic every so often. 
See following attached image in which all lines were drawn at a roughly
consistent speed.  Reproducible on desktop PC and Surface Pro 4

Reproducible: Always

Steps to Reproduce:
1.  Load Spacing Speed B preset (attachment to follow)
2.  Create an image around 2K in size.
3.  Draw a sequence of strokes until one of them breaks up into rectangles, as
in the example image.



Note: a useful application for controlling spacing with speed is to optimise
presets so that they are smooth when drawing slowly, and fast when drawing
broadly (at the expense of smoothness).  The example preset is demonstrative of
this particularly at larger scales.  The above issue makes it unusable for this
purpose.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 363316] New: Strokes pause momentarily at regular intervals

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363316

Bug ID: 363316
   Summary: Strokes pause momentarily at regular intervals
   Product: krita
   Version: 3.0 Release Candidate
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

At some indeterminable point point while working on an image, something starts
interrupting strokes for a fraction of a second, approximately every second. 
The problem can be fixed  temporarily by flattening the layers or restarting
Krita.

This occurs on both a desktop and Surface Pro 4 running Windows 10 64 bit.

Reproducible: Sometimes

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] [WACOM] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #20 from Chris Jones  ---
There's still a short straight line at the start of strokes in normal and
full-screen mode in krita-3.0-Beta-master-962bfe1-x64

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 362032] krita won't show menu dropdown in fullscreen mode on 3.0 alpha git f38b47e

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362032

Chris Jones  changed:

   What|Removed |Added

 CC||ch...@outlook.com

--- Comment #2 from Chris Jones  ---
Note that this is a problem with Full Screen Mode (ctrl-shift-f ), not to be
confused with Show Canvas Only (tab), which of course hides menus by design.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

--- Comment #8 from Chris Jones  ---
Created attachment 98470
  --> https://bugs.kde.org/attachment.cgi?id=98470=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

--- Comment #6 from Chris Jones  ---
Ok, it looks like the same opacity glitch problem happens on the desktop as
well.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

--- Comment #5 from Chris Jones  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

--- Comment #4 from Chris Jones  ---
Created attachment 98464
  --> https://bugs.kde.org/attachment.cgi?id=98464=edit
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  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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360541] Low resolution canvas on Surface Pro 4 with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360541

--- Comment #12 from Chris Jones  ---
I'm at 200%.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 332386] transform tool preview breaks when toggling layer visibility

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=332386

--- Comment #7 from Chris Jones  ---
Repeating the steps in my original post, the problem appears resolved.  I
couldn't reproduce rebuilders...@gmail.com's error, although I'm not certain
I'm replicating the steps in exactly the same way.  2.x often exhibits strange
behaviour on a second open document - could it be related to this?  I haven't
tested 3.0 enough to encounter issues with a second document yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361635] New: Deleted workspace returns on restart

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361635

Bug ID: 361635
   Summary: Deleted workspace returns on restart
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

After deleting a workspace and then restarting Krita, the workspace reappears
in the menu.  When working on refining a workspace, this can result in multiple
iterations with the same name.

Reproducible: Always

Steps to Reproduce:
1. Click on "Choose Workspace", select a workspace and delete it
2. Restart Krita
3. Click on "Choose Workspace" again, and see that the deleted workspace has
returned

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360541] Low resolution canvas on Surface Pro 4 with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360541

--- Comment #9 from Chris Jones  ---
Created attachment 98319
  --> https://bugs.kde.org/attachment.cgi?id=98319=edit
Image size fields squashed

I'm posting this here since it's probably a side effect of the hidpi flag being
disabled.  2.99.89.0 fixes the blurry/low res canvas and icons issue, but
presents a couple of new problems on the Surface Pro 4:

1.  The Image Size entry fields are squashed shut, making it impossible to set
a new custom image size (see attachment).

2.  The toolbox icons are now tiny, and selecting a larger size just spaces
them further apart.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #15 from Chris Jones  ---
Created attachment 98313
  --> https://bugs.kde.org/attachment.cgi?id=98313=edit
Stroke glitch in krita_x64_2.99.89.0

Still produces a little straight line at the start of fast curved strokes in
krita_x64_2.99.89.0.  Tablet log attached.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360541] Low resolution canvas on Surface Pro 4 with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360541

--- Comment #6 from Chris Jones  ---
You're probably already on top of this, but on closer inspection I've found
that the problem also occurs with OpenGL on, as ramskulls...@gmail.com
described above.  It's not quite as evident when zoomed out (which is how I
usually work), however when zoom is set to 100% the canvas is actually
displayed at 200%.

This also affects many of the icons, as well as the popup palette, which
appears as twice the normal size and half the resolution.  The brush presets in
the docker and the Advanced Color Selector are also blurry/low res.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359575] Processing after each stroke interrupts consecutive strokes

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359575

--- Comment #5 from Chris Jones  ---
To be clear, the interruptions occur irrespective of whether Instant Preview
Mode or OpenGL are enabled.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

--- Comment #2 from Chris Jones  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359533] Pop Up Palette Colour Selector is Too Small

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359533

--- Comment #2 from Chris Jones  ---

I forgot to suggest making it customisable, so yes that would be my preference
as well.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #14 from Chris Jones  ---
Just the defaults with basic smoothing.  I'll keep an eye out for the next
build.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359575] Processing after each stroke interrupts consecutive strokes

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359575

--- Comment #3 from Chris Jones  ---
That does appear to have made a slight improvement, however strokes are still
delayed frequently.  Sometimes after drawing several quick strokes, pausing for
around 5 seconds and drawing another stroke there is a delay, and then drawing
a stoke every 2-3 seconds thereafter causes a delay every time.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359575] Processing after each stroke interrupts consecutive strokes

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359575

--- Comment #1 from Chris Jones  ---
I now find this is reproducible on the SP4 in krita3-prealpha3-de0d43d .
"Updating..." appears much more briefly than on the desktop, but still
interrupts the stroke.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #12 from Chris Jones  ---
I find this is much improved now, however there is still a slight glitch at the
start of each stroke.  When drawing fast circles this appears as a little hook
on the SP4, and a short straight line on the desktop.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360588] New: Brush is smoother and less laggy with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360588

Bug ID: 360588
   Summary: Brush is smoother and less laggy with OpenGL turned
off
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

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

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360541] Low resolution canvas on Surface Pro 4 with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360541

--- Comment #2 from Chris Jones  ---
That is weird.  Definitely choppier here, especially at higher resolutions
(e.g. 7000 x 4500).  Should I make a separate report?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360541] New: Low resolution canvas on Surface Pro 4 with OpenGL turned off

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360541

Bug ID: 360541
   Summary: Low resolution canvas on Surface Pro 4 with OpenGL
turned off
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

With OpenGL turned off, the canvas resolution is at 200% instead of 100% when
Windows is set to the default scaling of 200%.  With Windows scaling set to
100% the canvas is displayed correctly at 100% resolution, but this renders the
UI too small.

Note:  I usually find it preferable to turn OpenGL off when using Krita on the
Surface, since drawing is smoother, and the device heats up uncomfortably
(although Krita 3 seems to run quite warm even with OpenGL off, whereas 2.9x
was notably cooler with it off).

Reproducible: Always




krita3-prealpha3-9694dac, Surface Pro4 265GB i5, 8GB RAM, Windows 10

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #6 from Chris Jones  ---
Example image here:
https://www.dropbox.com/s/gzuf6d10bkxh7fk/krita3_circles.jpeg?dl=0

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

--- Comment #5 from Chris Jones  ---
Created attachment 97300
  --> https://bugs.kde.org/attachment.cgi?id=97300=edit
Stroke glitches on Surface Pro 4

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359171] paint strokes with tablet less fluent than in 2.9.6

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359171

Chris Jones  changed:

   What|Removed |Added

 CC||ch...@outlook.com

--- Comment #4 from Chris Jones  ---
Created attachment 97299
  --> https://bugs.kde.org/attachment.cgi?id=97299=edit
Stroke glitches on desktop PC

I experience a similar issue that afflicts both my desktop PC and Surface Pro
4.  I don't have quite the same regular pattern of glitches, but there are
occasional similar looking zig-zags when drawing straight lines.  When drawing
circles however, it manifests itself as more severe glitches as described and
illustrated in the thread here:
https://forum.kde.org/viewtopic.php?f=281=131138 .

Attached is the desktop tablet log file, SP4 log to follow.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359575] New: Processing after each stroke interrupts consecutive strokes

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359575

Bug ID: 359575
   Summary: Processing after each stroke interrupts consecutive
strokes
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: Brush engine
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

A few seconds after every brush stroke, "Updating..." appears in the lower
right.  If another stroke is started while that message is present, the stroke
is delayed for a second or so before it appears.  If the next stroke is drawn
before the message appears, there is no delay.

Reproducible: Always

Steps to Reproduce:
1. Disable OpenGL
2. Make a new image 7000 x 4500
3. Select any brush and draw a scribble
4. Wait until "Updating..." appears, and then try to draw another scribble
before it disappears.  See that there is a significant delay before the stroke
starts.



This is reproducible in Windows 10 with a mouse or tablet on a Quad Core
desktop PC with NVidia GeForce 9600GT, but I was unable to reproduce it on a
Surface Pro 4.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 359533] New: Pop Up Palette Colour Selector is Too Small

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359533

Bug ID: 359533
   Summary: Pop Up Palette Colour Selector is Too Small
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: color selectors
  Assignee: krita-bugs-n...@kde.org
  Reporter: ch...@outlook.com

As modern displays continue to increase in resolution, it is becoming ever more
difficult to accurately select colours with the popup palette.  Enlarging the
pop up colour selector would allow the Advanced Colour Selector to be dispensed
with, thereby freeing up screen real estate, which is especially valuable on
smaller screens such as tablets.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #11 from Chris Jones  ---
I'm changing it with Convert Image Color Space, but I get the same results with
Image Properties.  Is there somewhere else I should be changing it?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #15 from Chris Jones  ---
(In reply to Boudewijn Rempt from comment #13)
> Okay -- I think I get it now. I would in general warn against converting a
> multilayered image from one color model to another: keep working in the
> color model you are using, and only convert the final, rendered result.

In my particular case that's unavoidable, as clients often require multilayered
PSD files, and 16 bit files are too large to transfer easily.  I'd work
directly in 8 bit except the airbrush is not smooth and there's more brush lag,
but those are reports for another day. ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #9 from Chris Jones  ---
Well, all I know is this:

If I start with a 16 bit image using the default colour profile
(sRGB-elle-V2-g10.icc (Default)), and I change it to 8 bit, the profile
automatically changes to sRGB-elle-v2-srgbtrc.icc, which produces incorrect
results.

If I change it back to sRGB-elle-V2-g10.icc (Default) before converting though,
it produces correct results.

So unless it has adverse ramifications elsewhere, it would seem that when
starting with 16 bit using the default profile, it should stay that way when
converting to 8 bit.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #2 from Chris Jones  ---
I'm using 16 bit with sRGB-elle-V2-g10.icc (Default), and converting to 8 bit
sRGB-elle-V2-g10.icc (Default).  If I convert to 8 bit sRGB-elle-v2-srgbtrc.icc
as you suggest, it still changes the opacity.  If I start with a 16 bit
sRGB-elle-v2-srgbtrc.icc however, it does stay the same after converting to 8
bit.

This suggests to me that the issue then is that the default settings cause
things to change unexpectedly when converting the colour depth, and if the
default settings were used to begin with, there is no apparent way within Krita
to do this without affecting the appearance of layers using Overlay.

Also, I haven't tested all of the colour profiles (there are a lot of them!),
but so far none of the ones I've tested seem to allow solid white when using
Overlay.  Do any of them?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #3 from Chris Jones  ---
Correction: the default settings use 8 bit - the problem begins when starting
with a 16 bit image (as I typically do).

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

--- Comment #6 from Chris Jones  ---
Wait a sec - that's what it does already!  Sorry, getting confused. :)

When I select 8 Bits in the "convert Image Color Space" panel, it also
automatically changes the Profile to sRGB-elle-v2-srgbtrc.icc - and maybe
that's the problem right there.  Shouldn't it retain the same profile that the
image already uses?

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 356303] New: Overlay blend mode appears incorrect in a 16 bit image

[Chris Jones via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356303

Bug ID: 356303
   Summary: Overlay blend mode appears incorrect in a 16 bit image
   Product: krita
   Version: 2.9.9
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Color models
  Assignee: krita-bugs-n...@kde.org
  Reporter: cjo...@chrisj.com.au

The opacity of a layer or brush set to Overlay blend mode in a 16 bit image
produces a lower level of opacity than the same layer in an 8 bit image.

Reproducible: Always

Steps to Reproduce:
1. Create a new 16 bit image
2. Paint some grey on Layer 1
3. Set Layer 2 to Overlay and paint over the grey with white.  Note that the
strokes are grey rather than white
4. Convert the image to 8 bit and see the strokes on Layer 2 turn to opaque
white



Photoshop does not exhibit this behaviour - it displays the white as opaque
white regardless of the colour depth.  Saving the 16 bit image from Krita as a
.psd and reducing the colour depth to 8 bit in Photoshop retains Layer 2's
original grey appearance however.

-- 
You are receiving this mail because:
You are watching all bug changes.