On Thu, 3 Oct 2024 09:35:51 GMT, Lukasz Kostyra <[email protected]> wrote:
> Contrary to issue description, the problem was not because we referenced a
> texture after it was freed, but we referenced an RTT that we just tried to
> allocate and failed to do so because of lack of space in Prism's vram pool.
> In case of attached `WebViewAnimationTest.java` test app, the problem exists
> because WebView tries to allocate a new RTT for newly opened WebView scene
> and the Prism pool does not have 16MB needed while previous WebView is still
> being displayed. Only after the old WebView is disposed of, then the RTT
> allocation can proceed and WebView can continue as normal.
>
> I looked around and did not find other solution than adding the null-checks
> to silence the NPE being thrown. NPE was originally in `RTImage.java`,
> however after adding a null check there triggered another NPE in
> `WCGraphicsPrismContext.java`, so I also added another null check there.
> Upper layers of web module seem to handle those just fine, the NPEs
> disappeared after that and the test still works properly once the pool gets
> enough room to display.
>
> All of our tests run fine with this change (I do not expect any major
> regressions, as this happens only with a very limited memory pool scenario -
> it was extremely hard and time consuming to trigger this bug on the test app
> with default 512MB pool limit). For the test app, it might take a couple
> frames until the old WebView is disposed of and there is enough room for new
> WebView's RTT in the pool, after that the scene renders properly.
modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/RTImage.java line
120:
> 118: if (txt == null) {
> 119: log.fine("RTImage::getTexture : return null because rt
> texture not allocated");
> 120: return null;
If `RTImage.getTexture()` can return `null`, then L147 should probably also
check for `null` before calling `readPixels()`.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1590#discussion_r1788512967
