JDK-8112047 : Mac: NPE encountered when call to renderToImage
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2011-04-05
  • Updated: 2015-06-16
  • Resolved: 2011-08-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
fx2.0Fixed
Related Reports
Blocks :  
JDK-8113631 - JFXPanel doesn't work with ES2, on Mac
Relates :  
JDK-8114426 - Prism/ES2: FX application with multiple stages throws GLException on Windows
Description
Running renderToImage toy gives the following NPE

java.lang.NullPointerException
        at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:52)
        at com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:48)
        at com.sun.javafx.tk.quantum.QuantumToolkit$PlatformImage.getRT(QuantumToolkit.java:974)
        at com.sun.javafx.tk.quantum.QuantumToolkit$7.run(QuantumToolkit.java:1090)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
        at com.sun.prism.tkal.RenderJob.run(RenderJob.java:29)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Comments
After the fix for RT-15212 HelloRenderToImage sample should be working OK on Mac/Windows (except RT-15240).
05-08-2011
Submitted - RT-15240
21-07-2011
I've tested this bug on Mac and RenderToImage works. Today I've noticed that after resizing RenderToImage prints error message to the console: [java] ERROR: PrismPen / FX threads co-running: DIRTY: true UPLOAD: false WAITING: 0 [java] FX: java.lang.Thread.dumpThreads(Native Method) [java] FX: java.lang.Thread.getAllStackTraces(Thread.java:1511) [java] FX: com.sun.javafx.tk.quantum.QuantumRenderer.checkRendererIdle(QuantumRenderer.java:234) [java] FX: com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:339) [java] FX: javafx.scene.Scene$ScenePulseListener.synchronizePGScene(Scene.java:1463) [java] FX: javafx.scene.Scene$ScenePulseListener.access$1100(Scene.java:1453) [java] FX: javafx.scene.Scene.renderToImage(Scene.java:917) [java] FX: javafx.scene.Scene.renderToImage(Scene.java:899) [java] FX: helloworld.HelloRenderToImage.updateScene(HelloRenderToImage.java:137) [java] FX: helloworld.HelloRenderToImage.access$000(HelloRenderToImage.java:23) [java] FX: helloworld.HelloRenderToImage$4.handle(HelloRenderToImage.java:145) [java] FX: helloworld.HelloRenderToImage$4.handle(HelloRenderToImage.java:143) [java] FX: com.sun.scenario.animation.shared.TimelineClipCore.visitKeyFrame(TimelineClipCore.java:196) [java] FX: com.sun.scenario.animation.shared.TimelineClipCore.playTo(TimelineClipCore.java:137) [java] FX: javafx.animation.Timeline.impl_playTo(Timeline.java:177) [java] FX: com.sun.scenario.animation.shared.GeneralClipEnvelope.visitCycle(GeneralClipEnvelope.java:255) [java] FX: com.sun.scenario.animation.shared.GeneralClipEnvelope.timePulse(GeneralClipEnvelope.java:184) [java] FX: javafx.animation.Animation.impl_timePulse(Animation.java:803) [java] FX: com.sun.scenario.animation.shared.AnimationPulseReceiver.timePulse(AnimationPulseReceiver.java:85) [java] FX: com.sun.scenario.animation.AbstractMasterTimer.timePulseImpl(AbstractMasterTimer.java:360) [java] FX: com.sun.scenario.animation.AbstractMasterTimer$MainLoop.run(AbstractMasterTimer.java:280) [java] FX: com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:357) [java] FX: com.sun.javafx.tk.quantum.QuantumToolkit$10.run(QuantumToolkit.java:296) [java] QR: com.sun.prism.opengl.impl.gl2.GL2Impl.glFinish(Native Method) [java] QR: com.sun.prism.opengl.impl.GLDrawableImpl.swapBuffers(GLDrawableImpl.java:82) [java] QR: com.sun.prism.es2.ES2SwapChain.present(ES2SwapChain.java:132) [java] QR: com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:241) [java] QR: java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [java] QR: java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [java] QR: java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [java] QR: com.sun.prism.render.RenderJob.run(RenderJob.java:29) [java] QR: java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [java] QR: java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [java] QR: com.sun.javafx.tk.quantum.QuantumRenderer$ObservedRunnable.run(QuantumRenderer.java:70) [java] QR: java.lang.Thread.run(Thread.java:637) Is it a known issue?
21-07-2011
Have you tested this bug on Mac? Note that getting ES2 to work on Windows is only for internal developer convenience (it allows dev to work on OpenGL bugs on Windows) and isn't the primary goal.
21-07-2011
The cause of the new exception is that the Prism rendering context and the Glass rendering contexts aren't shared on Windows (implemented on Mac along with RT-13728). That is if someone creates a shader on the Prism rendering context, then any attempt to use the shader on any Glass rendering context fails. In particular, glUseProgram fails with the swallowed OpenGL error - GL_INVALID_VALUE. Not sure why the scenario worked fine for me with the initial version of the fix for RT-13728. It's likely that the problem with the sharing of the rendering contexts on Windows will be fixed as a part RT-14811. Anyway, I'm going to start working on RT-14811 and I'll return to the renderToImage scenario when RT-14811 is fixed.
13-07-2011
I've tested the scenario with the final version of the fix for RT-13728 applied. 1. Mac - RenderToImage works fine 2. Windows - RenderToImage shows stage (the context of the stage is back) and throws RuntimeException. The stack trace is below The strange thing is that RenderToImage worked fine for me on Windows when I tested it before submitting a review request for the fix for RT-13728. Looks like the exception caused by one of the recently pushed changesets. I'll try to investigate it further. Here's the stack trace: [java] java.lang.RuntimeException: Error creating framebuffer object with size 320x480 (status code is 0x0) [java] at com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:171) [java] at com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:49) [java] at com.sun.scenario.effect.impl.prism.ps.PPSDrawable.create(PPSDrawable.java:50) [java] at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.createCompatibleImage(PPSRenderer.java:146) [java] at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.createCompatibleImage(PPSRenderer.java:60) [java] at com.sun.scenario.effect.impl.ImagePool.checkOut(ImagePool.java:166) [java] at com.sun.scenario.effect.impl.Renderer.getCompatibleImage(Renderer.java:118) [java] at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PPSRenderer.java:151) [java] at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PPSRenderer.java:60) [java] at com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:491) [java] at com.sun.javafx.sg.prism.NGNode.renderNodeBlendMode(NGNode.java:179) [java] at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:99) [java] at com.sun.javafx.sg.prism.NGGroup.doRender(NGGroup.java:298) [java] at com.sun.javafx.sg.prism.NGGroup.doRender(NGGroup.java:27) [java] at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1035) [java] at com.sun.javafx.tk.quantum.PaintRunnable.paintImpl(PaintRunnable.java:138) [java] at com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:238) [java] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [java] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [java] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [java] at com.sun.prism.render.RenderJob.run(RenderJob.java:29) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [java] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [java] at com.sun.javafx.tk.quantum.QuantumRenderer$ObservedRunnable.run(QuantumRenderer.java:70) [java] at java.lang.Thread.run(Thread.java:619)
13-07-2011
Assign to Dmitry, since it is related to RT-13728 which he is working on.
01-07-2011
i gave it a try and no luck in setOnShow I am calling scene.renderToImage which return null :( and NPE in ES2RTTexture.create
01-06-2011
Will Window.setOnShown() works for you? /** * Called just after the Window is shown. */ public final void setOnShown(EventHandler<WindowEvent> value)
01-06-2011
Question is how to find out that stage is already visible. In your sample you call render after pressing a button - obviously stage is already visible at that stage. In my case I have fully automatic tests which run as a part of hudson build and I can't depend on an user input. So either we should have an API which gives me info that stage is visible (a blocking call?) or call the update function as a part of platform initialization
30-05-2011
Yes, we know that ES2Context.updateRenderTarget isn't call early enough. Have you taken a look at the test program attached in RT-13712? The workaround is to only call renderToImage after you have a visible Stage. Is this doable in your case?
27-05-2011
I am still affected by this bug. RT-13712 fix didn't help. It seems that function ES2Context.updateRenderTarget is never called and therefore currentGL is not set
27-05-2011
Lower Priority to medium. With the fix to RT-13712, we believe most users should have no problem to do renderToImage (see the attached test program) on Mac.
24-05-2011
The fix to RT-13712 might be sufficient for the AT team to do what they need with RenderToImage.
24-05-2011
Assign to Chien for evaluation.
11-05-2011
happening on Mac platform. Blocking our testing infrastructure
09-05-2011