Re: Huge JavaFX performance drop in Debian Jessie

Tue, 22 Dec 2015 07:54:06 -0800

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
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

Reply via email to