Created attachment 125061 [details]
Screenshot of rendering issue

Created attachment 125062 [details]
How the image should look like

Created attachment 125063 [details]
How the image exports wrong

Sorry, file was too big. Here is the Krita document which has the rendering issue for me:

https://www.dropbox.com/s/aliupae079thuv8/test_bug_416172.kra?dl=0

I just found out that it doesn't seem happen in the 4.1.7 appimage with the same file, so it seems to be a regression.

With the 4.2.8 appimage and the Jan08 4.3.0 prealpha appimage, I have no problems with the rendered image and a .png exported image.

I tried making minor changes to the vector squares and text then saved and reopened but no problems.


Krita

 Version: 4.2.8
 Languages: en_GB, en
 Hidpi: true

Qt

  Version (compiled): 5.12.5
  Version (loaded): 5.12.5

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.19.0-6-amd64
  Pretty Productname: Debian GNU/Linux 10 (buster)
  Product Type: debian
  Product Version: 10

OpenGL Info
 
  Vendor:  "NVIDIA Corporation" 
  Renderer:  "GeForce GTX 750 Ti/PCIe/SSE2" 
  Version:  "4.6.0 NVIDIA 418.74" 
  Shading language:  "4.60 NVIDIA" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:    QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
     Version: 4.6
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsOpenGLES: true 
  isQtPreferOpenGLES: false 

Hardware Information

  GPU Acceleration: auto
  Memory: 16039 Mb
  Number of Cores: 8
  Swap Location: /tmp

Current Settings

	Current Swap Location: /tmp
	Undo Enabled: 1
	Undo Stack Limit: 18
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 360
	Use Backup Files: 1
	Number of Backups Kept: 1
	Backup File Suffix: ~
	Backup Location: Same Folder as the File
	Use Win8 Pointer Input: 0
	Use RightMiddleTabletButton Workaround: 0
	Levels of Detail Enabled: 1
	Use Zip64: 0

I could not reproduce this bug neither with 4.2.8 packaged dmg, or master dc7d037b5e0.

Rebecca, could you attache your system information with the "Current Settings" listing?

Krita

 Version: 4.2.8
 Languages: en_US, es, ja
 Hidpi: true

Qt

  Version (compiled): 5.12.5
  Version (loaded): 5.12.5

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: darwin
  Kernel Version: 18.7.0
  Pretty Productname: macOS Mojave (10.14)
  Product Type: osx
  Product Version: 10.14

OpenGL Info
 
  Vendor:  "Intel Inc." 
  Renderer:  "Intel(R) Iris(TM) Graphics 6100" 
  Version:  "4.1 INTEL-12.10.14" 
  Shading language:  "4.10" 
  Requested format:  QSurfaceFormat(version 3.2, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CoreProfile) 
  Current format:    QSurfaceFormat(version 4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CoreProfile) 
     Version: 4.1
     Supports deprecated functions false 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsOpenGLES: false 
  isQtPreferOpenGLES: false 

Hardware Information

  GPU Acceleration: desktop
  Memory: 8192 Mb
  Number of Cores: 4
  Swap Location: /Users/daedalus

Current Settings

	Current Swap Location: /Users/daedalus
	Undo Enabled: 1
	Undo Stack Limit: 25
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 0
	Use Backup Files: 1
	Number of Backups Kept: 1
	Backup File Suffix: ~
	Backup Location: Same Folder as the File
	Use Win8 Pointer Input: 0
	Use RightMiddleTabletButton Workaround: 0
	Levels of Detail Enabled: 0
	Use Zip64: 0

Ah, sorry, I cut off the copy&paste. At the end is the whole system info.

Playing around with the settings, I found out:

When I remove my kritarc and kritadisplayrc, the rendering issue almost doesn't occur at all. Out of at least 50 tries, probably more, I had it happen twice. (So maybe the Krita versions I listed in my initial report as "working" for me also just have this issue super rarely instead of not at all? I always loaded several times, but not THAT often.)

Unfortunately, during testing I accidentally overwrote my config files as of yesterday, but with an older version, I get the rendering issue as well, but only sometimes. It can go well for 20 times or more, and then fail for 20 times. I can't find anything that influences it. This is the kritadisplayrc:

[General]
EnableHiDPI=false
EnableSingleApplication=true
LogUsage=true
OpenGLRenderer=auto
canvasState=OPENGL_SUCCESS
rootSurfaceFormat=bt709-g22

And the according Current Settings:

	Current Swap Location: /tmp
	Undo Enabled: 1
	Undo Stack Limit: 100
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 300
	Use Backup Files: 1
	Number of Backups Kept: 1
	Backup File Suffix: ~
	Backup Location: Same Folder as the File
	Use Win8 Pointer Input: 0
	Use RightMiddleTabletButton Workaround: 0
	Levels of Detail Enabled: 1
	Use Zip64: 0



Once I have access to my backup, I can retrieve the latest Krita configs. Not today though.


-------------------------
The complete system info with the settings used when I reported the bug:


Krita

 Version: 4.2.8
 Languages: en_US
 Hidpi: false

Qt

  Version (compiled): 5.12.5
  Version (loaded): 5.12.5

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.9.0-9-amd64
  Pretty Productname: Debian GNU/Linux 9 (stretch)
  Product Type: debian
  Product Version: 9

OpenGL Info

  Vendor:  "Intel Open Source Technology Center"
  Renderer:  "Mesa DRI Intel(R) Kabylake GT2 "
  Version:  "3.0 Mesa 13.0.6"
  Shading language:  "1.30"
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile)
  Current format:    QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
     Version: 3.0
     Supports deprecated functions true
     is OpenGL ES: false

QPA OpenGL Detection Info
  supportsDesktopGL: true
  supportsOpenGLES: true
  isQtPreferOpenGLES: false

Hardware Information

  GPU Acceleration: auto
  Memory: 15796 Mb
  Number of Cores: 4
  Swap Location: /tmp

Current Settings

	Current Swap Location: /tmp
	Undo Enabled: 1
	Undo Stack Limit: 100
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 300
	Use Backup Files: 1
	Number of Backups Kept: 1
	Backup File Suffix: ~
	Backup Location: Same Folder as the File
	Use Win8 Pointer Input: 0
	Use RightMiddleTabletButton Workaround: 0
	Levels of Detail Enabled: 1
	Use Zip64: 0

Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.

Could test with my current kritarc and kritadisplayrc from when I reported the bug. The rendering issue again is 100% reproducible. Copying the rc files over to my docker, I can now reproduce the rendering issue 100% with my current master docker build as well. 

The good news: the intermittent crashes I get with the 4.2.8 appimage with those rc files, I couldn't reproduce with the nightly appimage nor the docker build at all despite A LOT of tries. That seems to be fixed.

I'm going to attach the rc files.

Created attachment 125122 [details]
kritarc that causes the issue

Created attachment 125123 [details]
kritadisplayrc that causes the issue

With those settings files I see the issue, but I also see lots of other problems like missing menu entries...

The issue seems to be with the line

rootSurfaceFormat=bt709-g22

in kritadisplayrc.

I have no idea how you managed to actually set that on Linux, since it's in the HDR tab which is hidden on Linux...

No... That line gets added automatically at some point, and isn't the problem. I guess that after closing Krita and removing it, some other settings got saved that fixed the issue.

Created attachment 125169 [details]
original kritarc sample after my use

My oldest config backup folder, dated 02-Nov-2019, has the kritadisplayrc file containing that entry. Here is my current/usual kritadisplayrc file contents:

[General]
EnableHiDPI=true
EnableSingleApplication=true
LogUsage=true
OpenGLRenderer=auto
canvasState=OPENGL_SUCCESS
rootSurfaceFormat=bt709-g22

In the past, I have changed between Auto (OpenGL) and OpenGL while trying things out.

If I run the version 4.2.8 appimage using the kritarc and kritadisplayrc files provided by Rebecca in Comment 11 and Comment 12, I also have some missing sub-menu entries for every main menu item. However, those menu entries do work if you click them.

I can then open the 'test_bug_416172.kra' file with no displayed problems.

I was able to click the Export entry location and export it as .png with no problems.

If I start with fresh/default kritarc and kritadisplayrc files and then only replace the kritarc file with the one provided by Rebecca, I get the same results as noted above.

The kritarc file provided by Rebecca has a size of 49696 bytes.
If I use it and run krita, open the test file and export then close the file and quit, the kritarc file has grown in size by 485 bytes to 50181 bytes.
Note: This is not the 'Size on Disk' but the reported number of bytes in the file.
This can not be accounted for by her username being changed to my username in just two locations.

I attach this kritarc file in case anyone thinks it may be interesting.

The only other thing that occurs to me, and it may be totally irrelevant, is that Rebecca is using Debian 9 which is 'old-stable'. I run Debian 10 which is 'stable'.

I use KDE Neon user edition.

I have a feeling that this bug is just a random shapes rendering issue, something like mentioned in bug 411738. Shape are somehow rendered with wrong transformation offsets...

Let's track it with that bug and merge request https://invent.kde.org/kde/krita/merge_requests/194 then.

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