Re: Huge JavaFX performance drop in Debian Jessie
Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new alphas new alphas PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4
RE: Huge JavaFX performance drop in Debian Jessie
Chris, can you please check what the JFX thread does whilst the scroll-freeze (e. g. using jstack or jvisualvm)? It would be great to learn whether it is related to JDK-8145565. -Markus -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Chris Newland Sent: Dienstag, 22. Dezember 2015 00:03 To: openjfx-dev@openjdk.java.net Subject: Huge JavaFX performance drop in Debian Jessie Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag ES2ResourceFactory: Prism - createStockShader: Solid_TextureSecondPassLCD.frag ES2ResourceFactory: Prism - createStockShader: FillPgram_LinearGradient_PAD.frag ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag new alphas new alphas PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4
RE: Huge JavaFX performance drop in Debian Jessie
Just to understand "not supported GPU" better: Is there GPU-specific code in JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? -Markus -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Chien Yang Sent: Dienstag, 22. Dezember 2015 09:01 To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: > Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian > Wheezy to Debian Jessie and JavaFX performance has suffered a huge > drop :( > > Possibly not JavaFX related but native apps (firefox etc) all seem to > perform the same and glxgears runs full sync framerate and 350fps > unsynced. > > JavaFX stages open blank and can take 5 seconds to render. Trying to > scroll a scrollbar pegs the CPU (java process at 100%) and hangs the > app for 10s+. > > Previously stages opened in under 1s and scrolling was instant. > > My DemoFX test platform (Canvas based effects) seems to run the same > so it only appears to be windows / stages that are affected. > > It's an old (2010) system but JavaFX performance has dropped from slow > to unusable. > > Will keep investigating and test on my Debian desktop once I upgrade > it to Jessie. > > Cheers, > > Chris > @chriswhocodes > > JavaFX debug: > > Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension > initializeIfAvailable > INFO: Failed to initialize management extension > java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) > at > com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :695) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) > at java.lang.Thread.run(Thread.java:745) > > Prism pipeline init order: es2 sw > Using java-based Pisces rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO > mode Opting in for HiDPI pixel scaling Prism pipeline name = > com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so > from relative path > succeeded. > GLFactory using com.sun.prism.es2.X11GLFactory > (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism > pipeline: com.sun.prism.es2.ES2Pipeline > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from > relative path Maximum supported texture size: 2048 Non power of two > texture support = true Maximum number of vertex attributes = 16 > Maximum number of uniform vertex components = 16384 Maximum number of > uniform fragment components = 16384 Maximum number of varying > components = 32 Maximum number of texture units usable in a vertex > shader = 8 Maximum number of texture units usable in a fragment shader > = 8 Graphics Vendor: Intel Open Source Technology Center > Renderer: Mesa DRI Intel(R) IGD > Version: 2.1 Mesa 10.3.2 > vsync: true vpipe: true > Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so > from relative path Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.s > o > from relative path > Loaded > /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so > from relative path > ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag > new alphas > ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag > ES2ResourceFactory: Prism - createStockShader: > Texture_LinearGradient_PAD.frag > ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag > ES2ResourceFactory: Prism - createStockShader: >
Re: Huge JavaFX performance drop in Debian Jessie
Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000 nid=0x17f9 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800 nid=0x17e1 in Object.wait() [0x7fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800 nid=0x17e0 waiting on condition [0x7fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCollector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.java:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolkit.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x7fec4c08f800 nid=0x17df in Object.wait() [0x7fec70143000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) - locked <0xe0ffc670> (a java.lang.StringBuilder) "QuantumRenderer-0" #9 daemon prio=5 os_prio=0 tid=0x7fec4c04c000 nid=0x17de runnable [0x7fec7118b000] java.lang.Thread.State: RUNNABLE at com.sun.prism.es2.GLContext.nDrawIndexedQuads(Native Method) at com.sun.prism.es2.GLContext.drawIndexedQuads(GLContext.java:724) at com.sun.prism.es2.ES2VertexBuffer.drawQuads(ES2VertexBuffer.java:65) at com.sun.prism.impl.VertexBuffer.flush(VertexBuffer.java:105) at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:111) at com.sun.prism.impl.ps.BaseShaderContext.setRenderTarget(BaseShaderContext.java:747) at com.sun.prism.impl.BaseContext.setRenderTarget(BaseContext.java:121) at com.sun.prism.impl.BaseGraphics.(BaseGraphics.java:105) at com.sun.prism.impl.ps.BaseShaderGraphics.(BaseShaderGraphics.java:86) at com.sun.prism.es2.ES2Graphics.(ES2Graphics.java:42) at com.sun.prism.es2.ES2Graphics.
RE: Huge JavaFX performance drop in Debian Jessie
Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the JavaFX thread is waiting for is not locked by any other thread, particularly *not* the renderer. Never saw something like that. One more thing I noticed in your stacktrace: The prism font dispose has locked an object and now waits for exactly that object. That looks strange. How can a thread wait for an object which itself has locked?! -Markus -Original Message- From: Chris Newland [mailto:cnewl...@chrisnewland.com] Sent: Dienstag, 22. Dezember 2015 10:06 To: Chien Yang; Markus KARG Cc: openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000 nid=0x17f9 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800 nid=0x17e1 in Object.wait() [0x7fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800 nid=0x17e0 waiting on condition [0x7fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol lector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j ava:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki t.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java :95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x7fec4c08f800 nid=0x17df in Object.wait() [0x7fec70143000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.sun.glass.ui.InvokeLaterDispatcher.run(InvokeLaterDispatcher.java:126) - locked <0xe0ffc670> (a java.la
Re: Huge JavaFX performance drop in Debian Jessie
We require Pixel Shader 3 support and this GPU doesn't really have full HW support. Most drivers will attempt to emulate with somewhat mixed results. If this card were in a system running Windows we would automatically detect and fall back to SW. This isn't as easy to do in Linux, but maybe it would be possible (Chien might want to comment on the feasibility of detecting this on Linux). -- Kevin Markus KARG wrote: Just to understand "not supported GPU" better: Is there GPU-specific code in JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? -Markus -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Chien Yang Sent: Dienstag, 22. Dezember 2015 09:01 To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. - Chien On 12/21/2015 03:02 PM, Chris Newland wrote: Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to Debian Jessie and JavaFX performance has suffered a huge drop :( Possibly not JavaFX related but native apps (firefox etc) all seem to perform the same and glxgears runs full sync framerate and 350fps unsynced. JavaFX stages open blank and can take 5 seconds to render. Trying to scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app for 10s+. Previously stages opened in under 1s and scrolling was instant. My DemoFX test platform (Canvas based effects) seems to run the same so it only appears to be windows / stages that are affected. It's an old (2010) system but JavaFX performance has dropped from slow to unusable. Will keep investigating and test on my Debian desktop once I upgrade it to Jessie. Cheers, Chris @chriswhocodes JavaFX debug: Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable INFO: Failed to initialize management extension java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java :695) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(Launche rImpl.java:182) at java.lang.Thread.run(Thread.java:745) Prism pipeline init order: es2 sw Using java-based Pisces rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.es2.ES2Pipeline Loading ES2 native library ... prism_es2 Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory (X) Got class = class com.sun.prism.es2.ES2Pipeline Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from relative path Maximum supported texture size: 2048 Non power of two texture support = true Maximum number of vertex attributes = 16 Maximum number of uniform vertex components = 16384 Maximum number of uniform fragment components = 16384 Maximum number of varying components = 32 Maximum number of texture units usable in a vertex shader = 8 Maximum number of texture units usable in a fragment shader = 8 Graphics Vendor: Intel Open Source Technology Center Renderer: Mesa DRI Intel(R) IGD Version: 2.1 Mesa 10.3.2 vsync: true vpipe: true Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.s o from relative path Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from relative path ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag new alphas ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag ES2ResourceFactory: Prism - createStockShader: Texture_LinearGradient_PAD.frag ES2ResourceFact
Re: Huge JavaFX performance drop in Debian Jessie
This is the normal stack trace I would expect when waiting for rendering to complete and the rendering is taking a long time. So in short: I see nothing strange or remarkable about the stack trace. -- Kevin Markus KARG wrote: Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the JavaFX thread is waiting for is not locked by any other thread, particularly *not* the renderer. Never saw something like that. One more thing I noticed in your stacktrace: The prism font dispose has locked an object and now waits for exactly that object. That looks strange. How can a thread wait for an object which itself has locked?! -Markus -Original Message- From: Chris Newland [mailto:cnewl...@chrisnewland.com] Sent: Dienstag, 22. Dezember 2015 10:06 To: Chien Yang; Markus KARG Cc: openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000 nid=0x17f9 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800 nid=0x17e1 in Object.wait() [0x7fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800 nid=0x17e0 waiting on condition [0x7fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol lector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j ava:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki t.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java :95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at com.sun.glass.ui.gtk.GtkApplication$$Lambda$43/357920869.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) "Thread-2" #11 daemon prio=5 os_prio=0 tid=0x7fec4c08f800 nid=0x17df in Object.wait() [0x7fec70143000] java.lang.Thread.State: WAITING (on object moni
RE: Huge JavaFX performance drop in Debian Jessie
What I meant with "odd" is the fact that a thread is waiting for a lock instance which is not told by the stack trace as locked by another thread, and that there is a thread which is waiting for a lock obtained by itself. I haven't seen this patterns before, but I also must confess that I am not an expert in reading stack traces. ;-) -Markus From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Dienstag, 22. Dezember 2015 16:57 To: Markus KARG Cc: openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie This is the normal stack trace I would expect when waiting for rendering to complete and the rendering is taking a long time. So in short: I see nothing strange or remarkable about the stack trace. -- Kevin Markus KARG wrote: Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the JavaFX thread is waiting for is not locked by any other thread, particularly *not* the renderer. Never saw something like that. One more thing I noticed in your stacktrace: The prism font dispose has locked an object and now waits for exactly that object. That looks strange. How can a thread wait for an object which itself has locked?! -Markus -Original Message- From: Chris Newland [mailto:cnewl...@chrisnewland.com] Sent: Dienstag, 22. Dezember 2015 10:06 To: Chien Yang; Markus KARG Cc: openjfx-dev@openjdk.java.net Subject: Re: Huge JavaFX performance drop in Debian Jessie Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but it's probably only noticeable in these low powered GPUs. Slowdown is with LXDE+lightdm and also Gnome3. Markus, Here is what the threads are doing when the scrollbar is hanging (with es2) Regards, Chris 2015-12-22 09:00:30 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode): "Attach Listener" #14 daemon prio=9 os_prio=0 tid=0x7fec58001000 nid=0x17f9 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Prism Font Disposer" #13 daemon prio=10 os_prio=0 tid=0x7fec2c192800 nid=0x17e1 in Object.wait() [0x7fec3a5b2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0xe10486f8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at com.sun.javafx.font.Disposer.run(Disposer.java:93) at java.lang.Thread.run(Thread.java:745) "JavaFX Application Thread" #12 prio=5 os_prio=0 tid=0x7fec4c093800 nid=0x17e0 waiting on condition [0x7fec4412e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf67d7668> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt( AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterru ptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterrupt ibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at com.sun.javafx.tk.quantum.PaintCollector.waitForRenderingToComplete(PaintCol lector.java:157) at com.sun.javafx.tk.quantum.GlassScene.waitForRenderingToComplete(GlassScene.j ava:127) at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2410) at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:355) at com.sun.javafx.tk.Toolkit$$Lambda$359/1368562994.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:354) at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:381) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:510) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:490) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$404(QuantumToolki t.java:319) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/1617205338.run(Unknown
Re: Huge JavaFX performance drop in Debian Jessie
Hi Kevin, The JavaFX performance when forcing the sw pipeline is still much slower with Jessie than Wheezy so I'm hoping there is something I can do at the OS level to get back to previous sw performance. Will let you know if I find it! Cheers, Chris Sent from my iPhone > On 22 Dec 2015, at 15:52, Kevin Rushforth wrote: > > We require Pixel Shader 3 support and this GPU doesn't really have full HW > support. Most drivers will attempt to emulate with somewhat mixed results. If > this card were in a system running Windows we would automatically detect and > fall back to SW. This isn't as easy to do in Linux, but maybe it would be > possible (Chien might want to comment on the feasibility of detecting this on > Linux). > > -- Kevin > > > Markus KARG wrote: >> Just to understand "not supported GPU" better: Is there GPU-specific code in >> JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? >> >> -Markus >> >> -Original Message- >> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of >> Chien Yang >> Sent: Dienstag, 22. Dezember 2015 09:01 >> To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net >> Subject: Re: Huge JavaFX performance drop in Debian Jessie >> >> Hi Chris, >> >> JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a >> high likelihood that the drop in performance is caused by the switch from sw >> pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA >> 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing >> JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command. >> >> - Chien >>
Re: Huge JavaFX performance drop in Debian Jessie
Hi @all, i had just a quick look at the stack trace may be you can make your app perform better with setting javafx.animation.pulse. i have never used this by my own. (but may be you can slow down the pulse of repainting) there are much more options for debug and testing [1,2] On Linux maybe you can fallback to vesa driver for the old devices? and test the performance without intel driver? for an old PC the VESA driver has a better performance then the 'new' intel driver (card is not supported well enough) Cheers, Jens [1] https://community.oracle.com/thread/2390862?start=0&tstart=0 [2] https://bugs.openjdk.java.net/browse/JDK-8091497 Am Dienstag, den 22.12.2015, 18:13 + schrieb Chris Newland: > Hi Kevin, > > The JavaFX performance when forcing the sw pipeline is still much > slower with Jessie than Wheezy so I'm hoping there is something I can > do at the OS level to get back to previous sw performance. > > Will let you know if I find it! > > Cheers, > > Chris > > Sent from my iPhone > > > On 22 Dec 2015, at 15:52, Kevin Rushforth < > > kevin.rushfo...@oracle.com> wrote: > > > > We require Pixel Shader 3 support and this GPU doesn't really have > > full HW support. Most drivers will attempt to emulate with somewhat > > mixed results. If this card were in a system running Windows we > > would automatically detect and fall back to SW. This isn't as easy > > to do in Linux, but maybe it would be possible (Chien might want to > > comment on the feasibility of detecting this on Linux). > > > > -- Kevin > > > > > > Markus KARG wrote: > > > Just to understand "not supported GPU" better: Is there GPU > > > -specific code in > > > JavaFX? I thought JFX is using vendor-neutral APIs to access the > > > GPU? > > > > > > -Markus > > > > > > -Original Message- > > > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] > > > On Behalf Of > > > Chien Yang > > > Sent: Dienstag, 22. Dezember 2015 09:01 > > > To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net > > > Subject: Re: Huge JavaFX performance drop in Debian Jessie > > > > > > Hi Chris, > > > > > > JavaFX may run on Intel GMA 3150, but it is not a supported GPU. > > > There is a > > > high likelihood that the drop in performance is caused by the > > > switch from sw > > > pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA > > > 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try > > > forcing > > > JavaFX to use its sw pipe by specifying -Dprism.order=sw in the > > > run command. > > > > > > - Chien > > >
