Javafx: Tested/Confirmed Hardware (Gpu) Acceleration on Linux

JavaFX: Tested/confirmed hardware (GPU) acceleration on Linux

Ubuntu 12.04 and nVidia GTX 750 Ti (Official drivers):

www@www-MS-7577:~$ java -Dprism.verbose=true -jar JavaFXApp.jar
Prism pipeline init order: es2 sw
Using platform text rasterizer
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
    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
Maximum supported texture size: 16384
Maximum texture size clamped to 4096
Non power of two texture support = true
Graphics Vendor: NVIDIA Corporation
       Renderer: GeForce GTX 750 Ti/PCIe/SSE2
        Version: 4.4.0 NVIDIA 340.46
 vsync: true vpipe: true
new alphas
QuantumRenderer: shutdown

Is JavaFX 2.2 going to support GPU acceleration in Linux?

I believe JavaFX for Linux already supports hardware acceleration for some features based on this statement from the JavaFX 2.1 Linux Develop Preview Release Notes:

3D features are supported for Nvidia cards (proprietary drivers only).

Not entirely conclusive, as it does not explicitly mention hardware acceleration, but I think use of hardware acceleration is likely if you have the appropriate Nvidia card and driver installed. Potentially, over time, hardware acceleration support under Linux for other hardware and driver configurations may be added.

How to disable or bypass Hardware Graphics Acceleration(Prism) in JavaFX

Look at this forum: https://forums.oracle.com/message/11018975

Add this to your java execution:

-Dprism.order=j2d

That should do the trick.

How to force gpu usage with JavaFX?

For those who are trying to solve a similar issue, it might be coming from the java.exe executable not using the gpu you want as a default device, you can change that in Windows' settings.

Use java to find GPU specifications on windows

Try below code :

String line;
Process p = Runtime.getRuntime().exec("wmic PATH Win32_videocontroller GET description");
BufferedReader input = new BufferedReader(new InputStreamReader(p.getInputStream()));
while ((line = input.readLine()) != null) {
   System.out.println(line);
}
input.close();

Output on my computer:

Description

Intel(R) HD Graphics 520

Windows commands are

wmic PATH Win32_videocontroller GET description
wmic PATH Win32_videocontroller GET adapterram
wmic PATH Win32_videocontroller GET driverversion
wmic PATH Win32_videocontroller GET pnpdeviceid

Java Hardware Acceleration

1)
So far hardware acceleration is never enabled by default, and to my knowledge it has not changed yet. To activate rendering acceleration pass this arg (-Dsun.java2d.opengl=true) to the Java launcher at program start up, or set it before using any rendering libraries. System.setProperty("sun.java2d.opengl", "true"); It is an optional parameter.

2)
Yes BufferedImage encapsulates some of the details of managing the Volatile Memory because, when the BufferdImage is accelerated a copy of it is stored in V-Ram as a VolatileImage.

The upside to a BufferedImage is as long as you are not messing with the pixels it contains, just copying them like a call to graphics.drawImage(), then the BufferedImage will be accelerated after a certain non specified number of copies and it will manage the VolatileImage for you.

The downside to a BufferedImage is if you are doing image editing, changing the pixels in the BufferedImage, in some cases it will give up trying to accelerate it, at that point if you are looking for performant rendering for your editing you need to consider managing your own VolatileImage. I do not know which operations make the BufferedImage give up on trying to accelerate rendering for you.

3)
The advantage of using the createCompatibleImage()/createCompatibleVolatileImage()
is that ImageIO.read() does not do any conversion to a default supported Image Data Model.
So if you import a PNG it will represent it in the format built by the PNG reader. This means that every time it is rendered by a GraphicsDevice it must first be converted to a compatible Image Data Model.

BufferedImage image = ImageIO.read ( url );
BufferedImage convertedImage = null;
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment ();
GraphicsDevice gd = ge.getDefaultScreenDevice ();
GraphicsConfiguration gc = gd.getDefaultConfiguration ();
convertedImage = gc.createCompatibleImage (image.getWidth (), 
                                           image.getHeight (), 
                                           image.getTransparency () );
Graphics2D g2d = convertedImage.createGraphics ();
g2d.drawImage ( image, 0, 0, image.getWidth (), image.getHeight (), null );
g2d.dispose()

The above process will convert an image read in with the image io api to a BufferedImage that has a Image Data Model compatible with the default screen device so that conversion does not need to take place when ever it is rendered. The times when this is most advantageous is when you will be rendering the image very frequently.

4)
You do not need to make an effort to batch your image rendering because for the most part Java will attempt to do this for you. There is no reason why you cant attempt to do this but in general it is better to profile your applications and confirm that there is a bottleneck at the image rendering code before you attempt to carry out a performance optimization such as this. The main disadvantage is that it my be implemented slightly differently in each JVM and then the enhancements might be worthless.

5)
To the best of my knowledge the design you have outlined is one of the better strategies out there when doing Double Buffering manually and actively rendering an application.
http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html
At this link you will find a description of the BufferStrategy. In the description it shows a code snippet that is the recommended way to do active rendering with a BufferStrategy object. I use this particular technique for my active rendering code. The only major difference is that in my code. like you, I have created the BufferStrategy on an instance of a Canvas which I put on a JFrame.

Java rendering over remote desktop

I figured it out:

• When launching the remote connection, open the connection options.
• Go to Screen
• Go to color
• Choose 16 bits color.

Done.

---

Related Topics