SUMMARY In 32 bits, when a layer has colors with big values, they are displayed wrong when canvas acceleration is used. When canvas acceleration is disabled it seems to work ok. STEPS TO REPRODUCE 1. Open Krita and activate canvas acceleration in the settings 2. Create a 32 bits image 3. Set some component of the foreground color to a really big value, for example rgb(9999999562023526247432192,00, 0.0, 0.0) 4. Paint OBSERVED RESULT If values for the color components above some really big number are used, they are displayed wrong, as if some kind of overflowing was happening. If one disables the canvas acceleration those colos change and look apparently right. EXPECTED RESULT The colors with big values should look right. For example a color rgb(9999999562023526247432192,00, 0.0, 0.0) should look red, but looks black with a blue border. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2
Can you maybe make an attach an image like that? Preferably with a screenshot with how it looks and possibly also how it should look (if it's not obvious).
Hi. I made a video back then: https://www.dropbox.com/s/wb7l6xqxyof5220/2021-05-06%2011-28-16.mp4?dl=0 There it can be seen that the colors painted on the canvas are not the same as the ones selected. And that disabling canvas acceleration shows the right colors (although there seem to be stioll some white artifacts, I don't know if that's normal due to the high values).
Does it also happen if you use a new layer, not the background layer?
Yes, it also happens when painting on a new layer. And it produces also artifacts on the semitransparent areas, even if you are painting with a "good" color on the layer below. I think this is related to opengl rendering. Maybe some overflow related issue. The colors in the layer seem to be ok because if you disable canvas acceleration they look fine. I tried to find the issue in the code back then but got lost.
I see this happening in the 4.4.8 appimage on Debian 10 - but not in the 5.0.0-beta1 or the Aug 29 5.1.0-prealpha appimages. There may be a 'critical number' at which this happens. e.g. with 19000006784332389679104.00 it happens but with 15000006784332389679104.00 it does not happen and I can go from one to the other with repeated effect. However, that can vary each time I try it (by reducing to zero, painting and then entering a new very large number). Note: 5.0.0-beta1 onwards won't accept a large number pasted in. It highlights it in red and then forces it to 1.0 but you can type a large number in and it will be accepted. With 4.4.8, you can paste or type a large number in and it will be accepted.