Please try the new Direct3D 9 pipeline in 6uN EA

[brackeen]

Yes I agree it would be nice to have some api that would tell you which operations are accelerated.

Is there a RFE for this? If so, I'll vote for it.

If that and PhotoComposite get into Java 7, PulpCore could use the D3D pipeline for all rendering operations, on systems that supported it (currently it's doing homebrew software rendering).

EDIT for grammar

[MGodehardt]

Starting with 6uN you can assume that if the image (back-buffer)
is accelerated then most operations to and from it are
accelerated.

ok i will use this logic

here some test from me, works fine on this chipset, my real applet with lots of components which has normally a 20ms rendering time was speeded up to 6ms per frame, wow thats fast.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46

C:\TEMP\marcus>c:\programme\java\jre6\bin\java.exe -Dsun.java2d.trace=log -Dsun. java2d.d3d=True -classpath ".;c:\programme\java\jre6\lib\rt.jar" test16 [I] CheckAdaptersInfo [I] ------------------ [I] Adapter Ordinal  : 0 [I] Adapter Handle   : 0x10001 [I] Description      : ATI RADEON 9600 Series [I] GDI Name, Driver : \\.\DISPLAY1, ati2dvag.dll [I] Vendor Id        : 0x1002 [I] Device Id        : 0x4151 [I] SubSys Id        : 0x40361458 [I] Driver Version   : 6.14.10.6387 [I] GUID             : D7B71EE2-0211-11CF-1B6F3C60A1C2CB35 [I] ------------------ [I] InitD3D: successfully created Direct3D9 object [I] D3DGD_getDeviceCapsNative [I] D3DPPLM::CheckDeviceCaps: adapter 0: Passed [I] D3DContext::InitContext device 0 [I] D3DContext::ConfigureContext device 0 [I] D3DContext::ConfigureContext: successfully created device: 0 [I] D3DContext::InitDevice: device 0 [I] D3DContext::InitDefice: successfully initialized device 0 [V]   | CAPS_DEVICE_OK [V]   | CAPS_ALPHA_RT_PLAIN [V]   | CAPS_ALPHA_RTT [V]   | CAPS_OPAQUE_RTT [V]   | CAPS_LCD_SHADER | CAPS_BIOP_SHADER [V]   | CAPS_MULTITEXTURE [V]   | CAPS_TEXNONSQUARE Direct3D pipeline enabled on screen 0 D3DFillRect D3DFillRect D3DFillRect created offscreen image sun.awt.image.SunVolatileImage@128e20a accelerated=true volatile=true D3DFillRect D3DFillRect D3DDrawGlyphs sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit("D3D Surface (rend er-to-texture)", AnyAlpha, "D3D Surface") > paint took 25225 mikro seconds D3DFillRect D3DDrawGlyphs sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit("D3D Surface (rend er-to-texture)", AnyAlpha, "D3D Surface") > paint took 1004 mikro seconds

I had problems with WM_ERASEBACKGROUND on this chipset, will resizing it background gets erased by native code, thats why i asked for a method to disable background erasing ( like in the JFrame's ).

remember this

TESTCASE3: run test16 with 1.6 update 3 on my 945G it flickers when i move another application ( like calc.exe ) over my window, its caused by
Toolkit.getDefaultToolkit().sync() when i comment out this line it does not flicker, or when i set sun.awt.noerasebackground=true.

Nice would be a function like setEraseBackground(boolean) for heavyweight components :-)

This flicker happens on my 945 (Dell Dimension 5100) but not on a 865 ( Dell Dimension 3000 )


Hmm. Looks like there was some bug which triggered this cascade of issues.

this flickering does not happen when i disable D3D or when i run it on a different pc, i removed Toolkit.getDefaultToolkit().sync() still flickering

Hmm. Did you override update() method in your hw component? Because if you didn't
the default behavior is to clear the background:

yes have a look at java16, update is overwritten, its calling paint ( not at all the best, i use different code in my applets )

[Linuxhippy]

  Actually much of the implementation between the pipelines is shared,
  only the native part that deals with particular API is different.
  So we do get the benefit of stable opengl pipeline code.

Good to know that not a lot engineering-effort was duplicated

  The problem is that it appears that the manifacturers aren't that
  interested in quality opengl drivers on Windows - and only enough
  that big game titles work well. Unfortunately our stuff doesn't
  necessarily benefit from improvements made for games.
  There are big questions about future opengl viability on Windows.

Well the problem is some kind of chicken-egg. Almost nobody uses OpenGL on windows because hardware-support is bad, and hardware support is bad because nobody really uses it.
My hope was that java would be some of those "law breakers", although I can understand that from Sun's POV its much more improtant to be commercially sucessful than to help OpenGL

  Hey, no problems - you are entitled to asking these questions, you will be using
  this stuff (whether you want it or not =) . And these are legitimate concerns.

Well I want to use it of course and I am happy about the big leap foreward by jdk6uN.
Although its dangerous to introduce such changes in an update release - Java is a bit late in the battle for desktop - so the descision to do all this stuff in an JDK-update release is what I call brave. Only the naming is in my opinion confusing - wouldn't be Java-6.1 exactly what everybody would expect?
Well wel all know Sun's management only exist to confuse consumers and developers

Thanks for all your effort, lg Clemens

Games published by our own members! Check 'em out!

[trembovetski]

  FYI, b07 is out. It has a couple of  important fixes:
     http://download.java.net/jdk6/6u10/promoted/b07/changes/jdk6uN-b07.html
  It significantly improves performance of Netbeans (and other applications
  which use LCD and grayscale AA text simultaneously); and addresses
  issues on Intel chips (by disabling the pipeline - at least until
  the drivers problems are resolved).

  Thanks,
    Dmitri

[MGodehardt]

Will it be possible to disable  background erasing on native frames ? at the moment this can be done by specifying sun.awt.noerasebackground and sun.awt.erasebackgroundonresize.

my program will run as applet and application, so i cant set the global noerasebackground options :-(

I have a application which will disable the frame decoration and draw its own non rectangular frame, problem is the white rectangular native background, swing is doing it, why not allow other swing like things this also ?

Should i file a RFE for this ?

[MGodehardt]

@trembovetski

When you derive my test16 Frame from JFRame, no native background erase takes place, but when i resize ( make it bigger ) then its erasing the background strange behaviour.

What i need is native window ( a awt frame ) which can disable native background erasing in all cases, so i can develop for e.g. a program which has a non rectangular window ( for e.g. a java clock :-) ).

On some gfx cards window resizing flickers ( check my last post its a nvidia card which is having this problem ), on a resize the native background erase is triggered, if a awt frame has a function like

disableNativeBackgroundErase

have a look at sun.awt.windows.WCanvasPeer

[trembovetski]

As I mentioned before, no API changes are allowed in an update release.
If you want this to be addressed in jdk7, file an RFE for the AWT team..

Dmitri

[trembovetski]

Also, AFAIK non-rectangular and translucent windows are being worked on for Java 7.

Dmitri

[Ken Russell]

@trembovetski: the WCanvasPeer.disableBackgroundErase() and Toolkit.disableBackgrounErase(Canvas) are non-public APIs that were added basically specifically for JOGL. JOGL calls these via reflection.

It sounds like there is a use case for adding a similar API for Frame or Window, even a non-public API. Could you help MGodehardt file an RFE? Associated RFEs are 6333613 and 6558510.

[MGodehardt]

Also, AFAIK non-rectangular and translucent windows are being worked on for Java 7.

Dmitri

This would be great, real transparent native windows :-)

Games published by our own members! Check 'em out!

[weston]

I know this is an old topic, but I just tried 6u10 and am pretty excited about the results I'd been working on some visualizations for a media player I'm writing for class (I'm doing gui, system architecture, and.. yep, anything visual - others are doing playback and xml library representation). So, the most cpu intensive visualization I was working on used something like 30% cpu before u10 and something like 5% after. I'm drawing lots of translucent BufferedImages to a VolatileImage and then drawing that to the screen. Some screens for fun, 'cause it's kinda perty (the numbers are a countdown btw, not fps - and the crappy image quality is because I only have Paint here ):<br>

[trembovetski]

That's pretty neat, thanks for sharing. Glad the pipeline
works for you!

Dmitri
Java2D Team