Skip to main content

How to detect hardware acceleration?

10 replies [Last post]
wzberger
Offline
Joined: 2004-08-31

Java 6u10 provides a method to modify widow opacity. On older machines, I assume without hardware acceleration, setting a window to the non-opaque mode leads to a very high CPU utilization. I wonder if there is a way to check the availability of hardware acceleration?

Tested with Java build 1.6.0_10-rc-b27 on Windows XP.

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
demonduck
Offline
Joined: 2008-03-14

> I don't believe this is a bug. This is a
> performance limitation of
> non-opaque windows on Windows platform - there's
> nothing we can
> do about it. Non-opaque windows were not originally
> intended for
> windows with high update rate. Every update means
> that we have
> to update whole window using GDI, which is not hw
> accelerated
> (in this case anyway).
> There's no magic here, the pixels need to get from
> system
> memory to vram. The faster the bus (like pcix), the
> better
> the performance. Older systems with PCI or AGP
> buses
> will have performance penalty.
> Thanks,
> Dmitri

Question: What is the possibility of writing directly to vram? Instead of writing to an int array in JVM memory and then doing some sort blit transfer to vram, why not just write directly to a portion of designated vram? I wonder if that would speed up certain ops?

Vram buffers are getting pretty big these days. I know the current API doesn't support this feature but what is the possibility of doing this sometime in the future.(SITF)?

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> I don't believe this is a bug. This is a
>> performance limitation of
>> non-opaque windows on Windows platform - there's
>> nothing we can
>> do about it. Non-opaque windows were not originally
>> intended for
>> windows with high update rate. Every update means
>> that we have
>> to update whole window using GDI, which is not hw
>> accelerated
>> (in this case anyway).
>> There's no magic here, the pixels need to get from
>> system
>> memory to vram. The faster the bus (like pcix), the
>> better
>> the performance. Older systems with PCI or AGP
>> buses
>> will have performance penalty.
>> Thanks,
>> Dmitri
>
> Question: What is the possibility of writing directly to vram? Instead of writing to an int array in JVM memory and then doing some sort blit transfer to vram, why not just write directly to a portion of designated vram? I wonder if that would speed up certain ops?
>

There's no way on Windows XP to do this. Translucent windows
are done through GDI on XP, so no possibility of hardware
acceleration beyond what we already do.

Anyway, VRAM is not supposed to be accessed from by the CPU.
The idea is that you upload the data there (preferably
not very often) and let the GPU handle it (using shaders,
or whatever), and then show it.

On some architectures for some particular framebuffers
there's advantage to writing directly to vram, but
Windows isn't one of them.

So just keeping your buffers in vram may not be the best
way especially if your application requires per-pixel access.

On Vista (where each window is pretty much a piece of
offscreen video memory) there is a way to do translucent
windows with full hw acceleration - that is, the data never
leaves vram. We'll be looking into
this for future releases.

Thanks,
Dmitri

> Vram buffers are getting pretty big these days. I know the current API doesn't support this feature but what is the possibility of doing this sometime in the future.(SITF)?
> [Message sent by forum member 'demonduck' (demonduck)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291188
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Java 6u10 provides a method to modify widow opacity. On older machines, I assume without hardware acceleration, setting a window to the non-opaque mode leads to a very high CPU utilization.

HW acceleration is actually disabled for the window
with opacity < 1.0 on all OS-es but Windows Vista
because of the incompatibility between
DirectX and GDI which were only fixed in Vista.

So if you're on XP the performance you see is from
sw-only rendering.

If you're using non-opaque windows (perpixel translucent),
it's a bit more complicated.

> I wonder if there is a way to check the availability of hardware acceleration?

There are many factors involved in performance in this case
besides hw acceleration (like whether your adapter is AGP or
PCIX) so I don't think it'd help if you just
check if hw acceleration is enabled. For one, it could
be enabled for one window and not another.

In general, one would use
GraphicsConfiguration.getImage/BufferCapabilities() to check
if hw acceleration is enabled. But like I said, they don't have
enough granularity to help.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

wzberger
Offline
Joined: 2004-08-31

Thanks for the info.

The problem is that my test app works fine on a modern machine with Vista and non-opaque window mode. On an older machine with XP the app is too slow so the additional eye candy which is provided by the non-opaque window mode should not appear.
That's why a auto-detection if hardware acceleration is supported would be a good feature. The result provided by BufferCapabilities seems to be good enough - I've also tested

[code]
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getAvailableAcceleratedMemory()
[/code]
If -1 is returned no HW-accel is supported - is the result better or equal to BufferCapabilities? AFAIK all these acceleration things are currently only supported on Windows - right?

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Thanks for the info.
>
> The problem is that my test app works fine on a modern machine with Vista and non-opaque window mode. On an older machine with XP the app is too slow so the additional eye candy which is provided by the non-opaque window mode should not appear.
> That's why a auto-detection if hardware acceleration is supported would be a good feature. The result provided by BufferCapabilities seems to be good enough - I've also tested

What's the hardware on the "older machine"?
You can set J2D_TRACE_LEVEL=4 env. variable in the
command line before starting your app, it will
print out the info on the video board/driver.

> [code]
> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getAvailableAcceleratedMemory()
> [/code]
> If -1 is returned no HW-accel is supported - is the result better or equal to BufferCapabilities? AFAIK all these acceleration things are currently only supported on Windows - right?

It is supported on other platforms (linux, solaris) if the OpenGL
pipeline is enabled (it's not by default). However, there's no
(easy) way to find out the
amount of available vram with OpenGL, so getAvailableAcceleratedMemory()
will return -1 even if the pipeline is enabled.
So it is better to use buffer/image caps to determine if the
pipeline is enabled.

Thanks,
Dmitri

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

wzberger
Offline
Joined: 2004-08-31

Hardware info for the older machine:

[code]
[I] OS Version = OS_WINXP Pro
[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal : 0
[I] Adapter Handle : 0x10001
[I] Description : NVIDIA GeForce2 MX/MX 400 (Microsoft Corporation)
[I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll
[I] Vendor Id : 0x10de
[I] Device Id : 0x0110
[I] SubSys Id : 0x88171462
[I] Driver Version : 6.14.10.5673
[I] GUID : {D7B71E3E-4250-11CF-FB61-1DA813C2CB35}
[E] D3DPPLM::CheckDeviceCaps: adapter 0: Failed (pixel shaders 2.0 required)
[I] ------------------
[E] D3DPPLM::CheckAdaptersInfo: no suitable adapters found
[E] InitD3D: failed to init adapters
[/code]

On the modern Vista machine the test app works also fine if I disable d3d support (sun.java2d.d3d=false) even if this causes a higher CPU utilization.

Dmitri Trembovetski

That is indeed a rather old board. I think it may not
be the board that's slow but the bus between the
cpu and vram - since non-opaque window send a bunch
of data on every repaint from system memory to
vram, the bus speed is very important.

The only suggestion I have is to provide the user with
the ability to turn off the effects. So if it's
really slow (perhaps you can detect it yourself, too -
time the repaints), then turn them off.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hardware info for the older machine:
>
> [code]
> [I] OS Version = OS_WINXP Pro
> [I] CheckAdaptersInfo
> [I] ------------------
> [I] Adapter Ordinal : 0
> [I] Adapter Handle : 0x10001
> [I] Description : NVIDIA GeForce2 MX/MX 400 (Microsoft Corporation)
> [I] GDI Name, Driver : \\.\DISPLAY1, nv4_disp.dll
> [I] Vendor Id : 0x10de
> [I] Device Id : 0x0110
> [I] SubSys Id : 0x88171462
> [I] Driver Version : 6.14.10.5673
> [I] GUID : {D7B71E3E-4250-11CF-FB61-1DA813C2CB35}
> [E] D3DPPLM::CheckDeviceCaps: adapter 0: Failed (pixel shaders 2.0 required)
> [I] ------------------
> [E] D3DPPLM::CheckAdaptersInfo: no suitable adapters found
> [E] InitD3D: failed to init adapters
> [/code]
>
> On the modern Vista machine the test app works also fine if I disable d3d support (sun.java2d.d3d=false) even if this causes a higher CPU utilization.
> [Message sent by forum member 'wzberger' (wzberger)]
>
> http://forums.java.net/jive/thread.jspa?messageID=286677
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

wzberger
Offline
Joined: 2004-08-31

To let the user decide to enable such an option is OK.

However I think possibly there still exists a performance bug. The test case below causes an avererage of 5% CPU utilization for opaque window and 50% CPU utilization for non-opaque windows even if the animated panel is placed on an opaque panel (tested on the older machine).

[code]
public class NonOpaqueWindowPerformanceTest extends JFrame
{
public NonOpaqueWindowPerformanceTest()
{
super();
setLayout(new BorderLayout());

JPanel p = new JPanel();
p.setBorder(new LineBorder(Color.GREEN));
p.setBackground(Color.RED);
p.setOpaque(true);

final JPanel p2 = new JPanel();
p2.setOpaque(true);
p2.setBorder(new LineBorder(Color.blue));
p2.setPreferredSize(new Dimension(300,300));
p.add(p2);

add(p);
//remarking the following line means 90% less CPU-utilization on Windows XP
setWindowNonOpaque(this);

setTitle(getClass().getSimpleName());
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setSize(800, 600);
setLocationRelativeTo(null);
setVisible(true);

new Thread(){
public void run()
{
while (true)
{
try
{
Thread.sleep(50);
}
catch (InterruptedException e)
{
e.printStackTrace();
}

EventQueue.invokeLater(new Runnable()
{
public void run()
{
Color color = new Color(new Random().nextInt(0xFFFFFF));
p2.setBackground(color);
}
});
}
}
}.start();
}

private void setWindowNonOpaque(Window w)
{
try
{
Class c = Class.forName("com.sun.awt.AWTUtilities");
Method m = c.getMethod("setWindowOpaque", Window.class, boolean.class);
m.invoke(null, w, false);
}
catch (Exception e)
{
e.printStackTrace();
}
}

public static void main(String[] args) throws Exception
{
EventQueue.invokeLater(new Runnable(){
public void run()
{
JFrame.setDefaultLookAndFeelDecorated(true);
new NonOpaqueWindowPerformanceTest();
}
});
}
}
[/code]

Dmitri Trembovetski

> even if the animated panel is placed on an opaque panel

This doesn't matter. If the window is made non-opaque,
then every component inside that window will have to
"pay the price".

I don't believe this is a bug. This is a performance limitation of
non-opaque windows on Windows platform - there's nothing we can
do about it. Non-opaque windows were not originally intended for
windows with high update rate. Every update means that we have
to update whole window using GDI, which is not hw accelerated
(in this case anyway).

There's no magic here, the pixels need to get from system
memory to vram. The faster the bus (like pcix), the better
the performance. Older systems with PCI or AGP buses
will have performance penalty.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> To let the user decide to enable such an option is OK.
>
> However I think possibly there still exists a performance bug. The test case below causes an avererage of 5% CPU utilization for opaque window and 50% CPU utilization for non-opaque windows even if the animated panel is placed on an opaque panel (tested on the older machine).
>
> [code]
> public class NonOpaqueWindowPerformanceTest extends JFrame
> {
> public NonOpaqueWindowPerformanceTest()
> {
> super();
> setLayout(new BorderLayout());
>
> JPanel p = new JPanel();
> p.setBorder(new LineBorder(Color.GREEN));
> p.setBackground(Color.RED);
> p.setOpaque(true);
>
> final JPanel p2 = new JPanel();
> p2.setOpaque(true);
> p2.setBorder(new LineBorder(Color.blue));
> p2.setPreferredSize(new Dimension(300,300));
> p.add(p2);
>
> add(p);
> //remarking the following line means 90% less CPU-utilization on Windows XP
> setWindowNonOpaque(this);
>
> setTitle(getClass().getSimpleName());
> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> setSize(800, 600);
> setLocationRelativeTo(null);
> setVisible(true);
>
> new Thread(){
> public void run()
> {
> while (true)
> {
> try
> {
> Thread.sleep(50);
> }
> catch (InterruptedException e)
> {
> e.printStackTrace();
> }
>
> EventQueue.invokeLater(new Runnable()
> {
> public void run()
> {
> Color color = new Color(new Random().nextInt(0xFFFFFF));
> p2.setBackground(color);
> }
> });
> }
> }
> }.start();
> }
>
> private void setWindowNonOpaque(Window w)
> {
> try
> {
> Class c = Class.forName("com.sun.awt.AWTUtilities");
> Method m = c.getMethod("setWindowOpaque", Window.class, boolean.class);
> m.invoke(null, w, false);
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> }
>
> public static void main(String[] args) throws Exception
> {
> EventQueue.invokeLater(new Runnable(){
> public void run()
> {
> JFrame.setDefaultLookAndFeelDecorated(true);
> new NonOpaqueWindowPerformanceTest();
> }
> });
> }
> }
> [/code]
> [Message sent by forum member 'wzberger' (wzberger)]
>
> http://forums.java.net/jive/thread.jspa?messageID=287511
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

wzberger
Offline
Joined: 2004-08-31

Thanks for the info.

Wolfgang