[krita] [Bug 445561] Krita 5 16bit integer colorspace canvas rendering is broken on M1

vanyossi bugzilla_noreply at kde.org
Sat Dec 4 01:09:58 GMT 2021


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

--- Comment #17 from vanyossi <ghevan at gmail.com> ---
Created attachment 144191
  --> https://bugs.kde.org/attachment.cgi?id=144191&action=edit
render offset stroke

1) Changed to 1024
2) The small tile does not render for 16i only (however there is something I
explain later), all other spaces show the colors and it can be painted. There
are no artifacts but the render never shows the image (only checkerboard).
After a good amount of strokes painting will start to get shown garbled (as the
screenshot from before)
3) Same as before.

== Based on what the canvas is rendering the behaviour is close to number 2)
but not quite. I usually test in a single color brush/stroke so it all seemed
ok until I started changing colors: On a fresh image supose I make a black
stroke, then a red one, then blue, etc.  switching colors on each stroke. The
freshly loaded image will not draw anything on canvas (but the thumbnail on
layer docker gets updated correctly and on time), however after a certain
amount of pixels the stroke you make starts to paint something (broken). From
there a long stroke will start cicling all the colors strokes you painted in
order. As if there was a misalign memory read only on 16i texture tiles that
causes the pixels to be rendered a lot later. There must be some place the
wrong format is set when we ask for 16i from the arm compiler.

I attach another image. here I create a 200x200 16i image. the image will not
show until I refresh the view many times (changing layer visibility i.e.) Once
the gradient is shown I paint a stroke, it will show as a garbled mess at the
coordinates of the stroke, but after refresh the new pixels get moved to the
top, clearly misaligned (attached image, left garbled, right after many
refresh). Refreshing the image will change the particular order of those pixels
until enough refresh is done and the stroke gets rendered correctly. This does
not happen if texture buffer is unticked. This fixed state only happens in
images/canvas updates below 449 by 449, any canvas update larger than that will
never be shown properly.

== about the patch
I painted and used the master with the patch loading different 16i images. On
loading the image or painting, there are no asserts.

Entering "KisOpenGLCanvas2::initializeGL()" KisOpenGLCanvas2(0x600003519810)
context()->shareGroup()->shares() = (QOpenGLContext(0x600000009dc0,
nativeHandle=QVariant(QCocoaNativeContext, ), format=QSurfaceFormat(version
4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 32,
redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8,
stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer,
swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile 
QSurfaceFormat::CoreProfile), screen=""), QOpenGLContext(0x6000000263d0,
nativeHandle=QVariant(QCocoaNativeContext, ), format=QSurfaceFormat(version
4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 32,
redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8,
stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer,
swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile 
QSurfaceFormat::CoreProfile), screen=""), QOpenGLContext(0x600000026160,
nativeHandle=QVariant(QCocoaNativeContext, ), format=QSurfaceFormat(version
4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 32,
redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8,
stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer,
swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile 
QSurfaceFormat::CoreProfile), surface=0x6000026be530, screen=""),
QOpenGLContext(0x60000008e290, nativeHandle=QVariant(QCocoaNativeContext, ),
format=QSurfaceFormat(version 4.1, options
QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 32, redBufferSize 8,
greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8,
samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0,
colorSpace QSurfaceFormat::DefaultColorSpace, profile 
QSurfaceFormat::CoreProfile), surface=0x600001021b70, screen=""))



Any colorspace switch (image -> colorspace)
ASSERT (krita): "m_textureTiles.size() > tile" in file
/Users/daedalus/developer/krita/repos/master/krita/libs/ui/opengl/kis_opengl_image_textures.h,
line 127

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



More information about the kde-mac mailing list