Description
The back buffer logic is able to recover if we ever lose the back buffer texture due to low vram conditions, but the code that performs dirty-region optimizations does not realize that it then needs to render the entire scene again.
This can show up if you have a small animation on a window where a lot of texture allocations are happening in another part of the window or in another window.
Run the attached test case which shows an animating red rectangle on a gradient background in one window and a canvas in the second window which is repeatedly setting large number of pixels using a pixel writer (a process that uses a lot of temporary vram). The large use of vram on the canvas window eventually causes the back buffer of the animating rectangle window to be reclaimed and the gradient will disappear. If you run the test case with dirtyopts=false then the background remains intact.
This can show up if you have a small animation on a window where a lot of texture allocations are happening in another part of the window or in another window.
Run the attached test case which shows an animating red rectangle on a gradient background in one window and a canvas in the second window which is repeatedly setting large number of pixels using a pixel writer (a process that uses a lot of temporary vram). The large use of vram on the canvas window eventually causes the back buffer of the animating rectangle window to be reclaimed and the gradient will disappear. If you run the test case with dirtyopts=false then the background remains intact.
Attachments
Issue Links
- duplicates
-
JDK-8096376 UI Rendered as Black with off-screen Canvas usage
- Resolved