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

vanyossi bugzilla_noreply at kde.org
Sat Nov 20 03:04:25 GMT 2021


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

--- Comment #9 from vanyossi <ghevan at gmail.com> ---
Created attachment 143754
  --> https://bugs.kde.org/attachment.cgi?id=143754&action=edit
broken behaviour

I've found the commit introducing this issue

the commit is part of the openGL buffered refactor. Somehow from commit
07a10c399b693326f5826217bb0c268aeafb7264

commit 07a10c399b693326f5826217bb0c268aeafb7264
Author: Dmitry Kazakov <dimula73 at gmail.com>
Date:   Tue Aug 31 17:14:45 2021 +0300

    Implement a reusable class for multibuffered rendering

    On OSX we have a huge problem with uploading any data on GPU. When we
    upload some data with a buffer and try to write into the same buffer
    again, the writing call is blocked until the previous data has finished
    uploading to the GPU. It makes paintGL() call to block up to 60 ms,
    which stops the main GUI thread and makes OSX to drop tablet events.

 16 bit integer colorspace is rendered wrong in openGL. The files can be saved
normally but its impossible to work in this colorspace in a arm macOS (Rosetta
or Native). The buffered approach is not the problem as the first buffered
"test" commit shows all colorspaces correctly. This bug is not present running
from an intel macOS.

I don't think it is an openGL or sillicon bug entirely since the "test" patch
works correctly (commit d60aa02cafcc0dd6d9a2881df097847d1a7388d8), I believe
there could be a bug at our implementation or maybe in QtOpenGL buffer
functions since we didn't use them before.

The video attached shows the wrong rendering changes depending on the moment it
get called for refresh, sometimes rendering correctly. An interesting hint to
perhaps find where the memory is getting misaligned.

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



More information about the kde-mac mailing list