Please try the new Direct3D 9 pipeline in 6uN EA

Java 2D
#41

@trembovetski

i have a applet/application which is doing the following pseudo code in the frame’s paint method

create a offscreen buffer on VRAM ( VolatileImage )
draw something on that offscreen buffer
draw the offscreen buffer on the screen ( offscreen buffer on VRAM is drawn thru drawImage to visible portion of VRAM ) blit is accelerated

thats the trace ( running it with java 1.6.0_03 and no special sun.java2d, except trace enabled )
DXFillRect
DXFillRect
sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
sun.java2d.windows.DDBlitLoops::Blit(“Integer RGB DirectDraw”, SrcNoEa, “Integer RGB DirectDraw”)

when i set sun.java2d.d3d=True i get ( D3D pipeline was actived correctly )
Direct3D pipeline enabled on screen 0
D3DFillRect
D3DFillRect
D3DDrawGlyphs
sun.java2d.windows.DDBlitLoops::Blit(“Integer RGB DirectDraw”, SrcNoEa, “Integer RGB DirectDraw”)

you are not using D3DBlitLoops ( this is confusing me ) when d3d is enabled, also time for rendering is around 6ms with d3d enabled and 4ms with d3d disabled, seems like d3d is broken or not working correct.

Ok now i give 6uN a try and trace looks like this :o (D3D pipeline was actived correctly)

Direct3D pipeline enabled on screen 0
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, “GDI”)

rendering time is 3ms, but can u please explain me the trace output, is it using the new d3d pipeline, i am confused …

this is output from trace J2D_TRACE_LEVEL=5

[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal : 0
[I] Description : Intel® 82945G Express Chipset Family
[I] GDI Name, Driver : \.\DISPLAY1, igxprd32.dll
[I] Vendor Id : 0x8086
[I] Version : 6.14.10.4764
[I] ------------------
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 0: Passed
[I] D3DContext::InitContext device 0
[I] D3DContext::ConfigureContext device 0
[I] D3DContext::ConfigureContext: successfully created device: 0
[I] D3DContext::InitDevice: device 0
[W] D3DContext::InitDevice: sync query not available
[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

something is wrong, if this version gets not fixed, a lot of existing applications get killed, from acceleration to software loop, oops

this happens when i draw the volatile image ( offscreen ) to onscreen ( scaling on the fly )

D3DFillRect
D3DFillRect
D3DDrawGlyphs
sun.java2d.loops.Blit$GeneralMaskBlit::Blit(“D3D Surface (render-to-texture)”, S
rcNoEa, IntRgb)
sun.java2d.loops.MaskBlit$General::MaskBlit(“D3D Surface (render-to-texture)”, S
rcNoEa, IntRgb)
sun.java2d.d3d.D3DSurfaceToSwBlit::Blit(“D3D Surface”, SrcNoEa, IntArgb)
sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntRgb)
sun.java2d.loops.TransformHelper::TransformHelper(IntRgb, SrcNoEa, IntArgbPre)

Note: this renders in 140ms, what happend ? u3 needs only 4ms

applets with version 1.6.0_03 are rendering this in 4 ms

DXFillRect
DXFillRect
sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)

I can give u a test applet/application if you want one :slight_smile:

#42

[quote] This build contains the new Direct3D 9-based Java2D pipeline,
which is enabled by default on Windows platform
[/quote]
I am a bit afraid by the fact D3D will be enable by default, I mean users can have driver probleme or incompatible display device or some bugs can still be hidden somewhere,so, shouldn’t be good to disable D3D by default ? I mean that way old APP wil still just run as fine as before and new app can request to turn it on , on the fly ? developper will take care of asking user to enable it or not on new APP, then user wont be disapointed if they install new java release and cant use/play anymore some app/games ? also if enabling d3d come from a user action and it does not work, user will know where his problem come from.

#43

It is working correctly. In u3 the d3d pipeline is built on the DirectX pipeline. There’s
not really a d3d blit from VI to the screen there. The D3DBlits are only used when
you do a BI->VI copy - then we’d use d3d’s texture mapping .

Yeah, there were lots of issues in b04, many were addressed in b06/07.

Me too =) I know that there were some bugs in b04 which would result in
something like what you’re seeing. This should have been addressed
in b06 and further in b07.

Well, one problem is that your chipset is Intel 945G. It’s
a pretty bad chip - meaning you don’t really get
that much of acceleration (it doesn’t even have hardware transforms,
not to mention pixel shaders), and the drivers are super-buggy.

See these bugs:
6612195: D3D: Netbeans editor is completely unusable with JDK 6uN [Intel 945G]
6599742: D3D: Text rendering becomes garbled on Intel 945G chipset

Which is why we now (as of b06) disable the pipeline on Intel 945G.
Interestingly, it is likely that you will see a performance improvement
because of that - the chip is that bad =)

The 965G chipset is better (HW transforms, pixel shaders), but the drivers
are still buggy, and performance is not so good:
6620073: D3D: running J2DBench restarts the driver on Vista [Intel G965]

We’re working with Intel on this bug as well as performance issues, they may
have fix. Until they do the pipeline is disabled on 965G as well.

Please do, I will make sure that it works correctly.

Thanks,
Dmitri

#44

I understand your concern. But here’s the problem: if the pipeline is not enabled by
default, only .001% of the users will ever enable it.

The old DirectX pipeline was showing its age and could not really
be improved, and performance was lacking especially with all the
new stuff that comes with JavaFX and Nimbus.

We will make sure that the pipeline is robust enough to be left
on by default. Which is why we have made the early builds
available - so that we can catch issues and fix them before
the release.

The good news is that on most modern boards it works
very well.

Thanks,
Dmitri

#45

What I wonder is whats the advantage of the D3D pipeline?

It does not seem to support many more boards than the OGL pipeline anymore because all boards which broke the OGL pipeline are also buggy enough to not run the D3D pipeline reliable. Furthermore its more limited than the OpenGL pipeline (e.g. drawing directly to screen / drawing VI to screen), and introcuces another backend which has to be maintained (OGL could have been the one and only successor on many major platforms like Windows, Linux and OSX). To make it even worse the OGL pipeline had much more testing, as it hasn’t been modified a lot for a long time.
However enabling the OGL pipeline by default could have lead to better OpenGL drivers in general, whereas the D3D pipeline suggests board and driver makers even more that investing in OpenGL development is a waste of money.

So although in general I am happy that Sun cares so much about desktop users now (which is the best news ever!), and although I think the D3D pipeline is also a masterpiece and Dimitri did a great job, I don’t see many advantages.
Furthermore I don’t think my moaning can change anything till the release of JDK6uN :wink:

Sorry for those not so kind words … just some thoughts written down. However all in all a great and impressive job you and the Java2D have done :slight_smile:
Thanks a lot!

lg Clemens

#46

@trembovetski

Here comes my small test programm test16.java and the starting programm test16.bat (so u can see what options i use )


set J2D_TRACE_LEVEL=5
d:\jre1.6ea\bin\java.exe -Dsun.java2d.trace=log -classpath ".;d:\jre1.6ea\lib\rt.jar" test16



/**************************************************************************************************
 *
 *************************************************************************************************/

import java.awt.*;
import java.awt.event.*;
import java.awt.image.*;

/**************************************************************************************************
 * Double buffering test with 1 backbuffer
 *************************************************************************************************/
public class test16 extends Frame
{
    private final static long serialVersionUID = 123456; // keep the compiler happy

    private final static int WIDTH = 200;
    private final static int HEIGHT = 200;

    private Image offscreen;

    /**********************************************************************************************
     *
     *********************************************************************************************/
    static public void main(String[] args)
    {
        test16 aFrame = new test16();
        aFrame.setBounds(0, 0, 800, 600);
        aFrame.setLayout(null);
        aFrame.setResizable(false);
        aFrame.setTitle("Java 1.6 Double Buffer Test");
        aFrame.setBackground(Color.red);
        aFrame.setVisible(true);
    }

    /**********************************************************************************************
     *
     *********************************************************************************************/
    private void createOffscreen()
    {
        if ( null != offscreen )
        {
            offscreen.flush();
            offscreen = null;
        }

        offscreen = getGraphicsConfiguration().createCompatibleVolatileImage(WIDTH, HEIGHT);
        System.out.println("created offscreen image " + offscreen + " accelerated=" + offscreen.getCapabilities(getGraphicsConfiguration()).isAccelerated() + " volatile=" + offscreen.getCapabilities(getGraphicsConfiguration()).isTrueVolatile());
    }

    /**********************************************************************************************
     *
     *********************************************************************************************/
    private void validateOffscreen()
    {
        if ( offscreen instanceof VolatileImage )
        {
            VolatileImage aImage = (VolatileImage)offscreen;

            if ( aImage.validate(getGraphicsConfiguration()) == VolatileImage.IMAGE_INCOMPATIBLE )
            {
                createOffscreen();

                // revalidate offscreen
                ((VolatileImage)offscreen).validate(getGraphicsConfiguration());
            }
        }
    }

    /**********************************************************************************************
     * is called when parts of the peer are damaged and needs redraw
     *********************************************************************************************/
    public void paint(Graphics gg)
    {
        long startTime = System.nanoTime();

        if ( null == offscreen )
        {
            createOffscreen();
        }
        validateOffscreen();

        Graphics ogr = offscreen.getGraphics();

        ogr.setColor(Color.blue);
        ogr.fillRect(0, 0, WIDTH - 20, HEIGHT - 20);

        ogr.setColor(Color.black);
        ogr.drawString("Hello", 20, 50);

        ogr.dispose();
        gg.drawImage(offscreen, 0, 0, WIDTH, HEIGHT, this);

        Toolkit.getDefaultToolkit().sync(); // flush the pipeline

        long stopTime = System.nanoTime();
        if ( (startTime > 0) && (stopTime > 0) && (stopTime > startTime) )
        {
            long diffTime = stopTime - startTime;
            if ( diffTime > 0 )
            {
                System.out.println("> paint took " + (diffTime / 1000) + " mikro seconds");
            }
        }
    }

    /**********************************************************************************************
     * triggered by repaint
     *********************************************************************************************/
    public void update(Graphics gg)
    {
        paint(gg);
    }
}

/*************************************************************************************************/

when i run this program with 6uN i get this output

GDIFillRect
D3DFillRect
created offscreen image sun.awt.image.SunVolatileImage@dd5b accelerated=true vol
atile=true
D3DFillRect
D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DSurfaceToGDIWindowSurfaceBlit::Blit(“D3D Surface”, AnyAlpha, "
GDI")

paint took 26626 mikro seconds
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.DrawGlyphList::DrawGlyphList(AnyColor, SrcNoEa, AnyInt)
sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, “GDI”)
paint took 11443 mikro seconds

the GDIFillRect is the background erase ( WM_ERASEBACKGROUND ) from the heavyweight Frame class

The red area in the frame is not painted by me, its the background set by setBackground
the white area is from the volatile image ( default color for a opaque image )
the blue area is from the fillrect

TESTCASE2: comment out validateOffscreen, screen will be red, the volatile image is NOT drawn ( compare with 1.6 update 3 where it works )

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

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

TESTCASE4: disable D3D with -Dsun.java2d.d3d=false with 6uN, GDI pipeline is used

I hope this helps

Question:

When i change Line 91 to this


gg.drawImage(offscreen, 0, 0, WIDTH * 2, HEIGHT * 2, this);

Would 6uN accelerate it ? its scaling a volatile image on the fly. I have a application/applet which can be scaled, it has one heavyweight component the Frame with a VolatileImage as backbuffers, all other components are lighweight and draw into this volatile image, which is then scaled, it would be great if scaling is accelerated and
if we can specify the interpolation mode ( bilinear would be a great improvement )

P.S.: Which gfx card is recommended for 6uN ???

Happy Halloween :slight_smile:

#47

The main reason is that the Direct3D drivers on windows are way better than
OpenGL. On Vista, for example, OpenGL drivers even now are extremely
flaky. Even on XP on the latest boards (from Nvidia, for example) the drivers
are so bad that our pipeline is pretty much DOA in the default configuration.

And the D3D pipeline does work on wider array of boards, although
with my recent change (requiring HW TnL) that array had somewhat
shrunk.

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.

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.

Note that the opengl pipeline was mostly intended for accelerated rendering
on X11 platforms (or, rather, no non-windows platforms), the fact that it
was relatively easy to make it work
on windows was a side effect of good design by Chris =)

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.

Thanks,
Dmitri

#48

Thanks a lot for the test.
It works much better on b06 (should be out soon - may be by the end of this week).

On my system I get this kind of output:


D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface")
> paint took 852 mikro seconds

Without the tracing:


> paint took 615 mikro seconds
> paint took 614 mikro seconds
> paint took 634 mikro seconds
> paint took 607 mikro seconds

With such simple case it’s hard to see the benefits of the acceleration, though.

It appears that there was a bug which I can not reproduce now on b06 - I
always get d3d-only operations, even for the ‘erase background’ fillRect.

Yeah, you have to validate vi before use. The fact that it used to work w/o it
is just luck.

Basically here’s what happens: when we detect that a VI (which is in VRAM) is copied
to a screen surface (the real GDI screen surface), we disable acceeleration in this VI
(and mark it lost) to avoid constant vram->system memory copies, which
are extremely slow. And if you don’t validate the VI you will never find out
that it is lost.

However, this situation should not have been there in the first
place. There are only few rare cases where our d3d onscreen support
could not be enabled and so a VI would be copied to the screen.

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

Yes, this is accelerated, including bilinear filtering. You can specify the
interpolating mode with setRenderingHint before the drawImage call.
So with this change (gg is now a Graphics2D object)


        gg.setRenderingHint(RenderingHints.KEY_INTERPOLATION,
                            RenderingHints.VALUE_INTERPOLATION_BILINEAR);
        gg.drawImage(offscreen, 0, 0, WIDTH*2, HEIGHT*2, this);

You’d get something like this:


D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface")

Basically any Nvidia or ATI board which has hardware support for pixel shaders
2.0 should do:
http://en.wikipedia.org/wiki/Pixel_shader

Boo! =)

Dmitri

#49

Having said all that it would be more efficient if you converted
your application to using the default BufferStrategy.

Dmitri

#50

My program has to be compatible with pre java 1.4 jvm’s where it uses normal offscreen buffers, so i used this vi double buffering

This is the output from java16 on a new desktop pc, this Radeon should have a v3.0 Pixel Shader

using update5, i think u ran java16 on update 6 ( which is not available for the public )


[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal  : 0
[I] Description      : Radeon X1300/X1550 Series
[I] GDI Name, Driver : \\.\DISPLAY2, atiumdag.dll
[I] Vendor Id        : 0x1002
[I] Version          : 7.14.10.532
[I] ------------------
[I] Adapter Ordinal  : 1
[I] Description      : Radeon X1300/X1550 Series
[I] GDI Name, Driver : \\.\DISPLAY1, atiumdag.dll
[I] Vendor Id        : 0x1002
[I] Version          : 7.14.10.532
[I] ------------------
[I] InitD3D: successfully created Direct3D9 object
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 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
[I] D3DGD_getDeviceCapsNative
[I] D3DPPLM::CheckDeviceCaps: device 1: Passed
[I] D3DContext::InitContext device 1
[I] D3DContext::ConfigureContext device 1
[I] D3DContext::ConfigureContext: successfully created device: 1
[I] D3DContext::InitDevice: device 1
[I] D3DContext::InitDefice: successfully initialized device 1
[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
GDIFillRect
D3DFillRect
created offscreen image sun.awt.image.SunVolatileImage@4b4333 accelerated=true v
olatile=true
D3DFillRect
D3DFillRect
D3DDrawGlyphs
sun.java2d.loops.Blit$GeneralMaskBlit::Blit("D3D Surface (render-to-texture)", S
rcNoEa, IntRgb)
sun.java2d.loops.MaskBlit$General::MaskBlit("D3D Surface (render-to-texture)", S
rcNoEa, IntRgb)
sun.java2d.d3d.D3DSurfaceToSwBlit::Blit("D3D Surface", SrcNoEa, IntArgb)
sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntRgb)
sun.java2d.loops.TransformHelper::TransformHelper(IntRgb, SrcNoEa, IntArgbPre)
> paint took 140065 mikro seconds
D3DFillRect
D3DDrawGlyphs
sun.java2d.loops.Blit$GeneralMaskBlit::Blit("D3D Surface (render-to-texture)", S
rcNoEa, IntRgb)
sun.java2d.loops.MaskBlit$General::MaskBlit("D3D Surface (render-to-texture)", S
rcNoEa, IntRgb)
sun.java2d.d3d.D3DSurfaceToSwBlit::Blit("D3D Surface", SrcNoEa, IntArgb)
sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntRgb)
sun.java2d.loops.TransformHelper::TransformHelper(IntRgb, SrcNoEa, IntArgbPre)
> paint took 51072 mikro seconds

i am using this version

java version “1.6.0_05-ea”
Java™ SE Runtime Environment (build 1.6.0_05-ea-b05)
Java HotSpot™ Client VM (build 1.6.0_05-ea-b05, mixed mode, sharing)

when this version is available for everybody i will rerun this test on the pc with the Radeon X1300 i also have a pc with Radeon 9600.

#51

Yes, I can reproduce this on b05 but not on b06.

Dmitri

#52

FYI: build b06 is out:
http://download.java.net/jdk6/binaries/

Unfortunately it doesn’t address issues on Intel chips, that’ll be in b07
(and by addressing I mean, sigh, disabling the pipeline on Intel chips).

Dmitri

#53

[quote]FYI: build b06 is out:
[/quote]
Tried it out, and it’s working great. The BufferStrategy way and old-school repaint() way are both appearing very smooth - no dropped frames like the b05 version. Keep up the good work!

#54

running test16.java with build06


D:\projects\eden\src>d:\jre1.6ea\bin\java.exe -Dsun.java2d.d3d=True -Dsun.java2d
.trace=log -classpath ".;d:\jre1.6ea\lib\rt.jar" test16
[I] CheckAdaptersInfo
[I] ------------------
[I] Adapter Ordinal  : 0
[I] Adapter Handle   : 0x10001
[I] Description      : Intel(R) 82945G Express Chipset Family
[I] GDI Name, Driver : \\.\DISPLAY1, ialmrnt5.dll
[I] Vendor Id        : 0x8086
[I] Device Id        : 0x2772
[I] SubSys Id        : 0x1ab1028
[I] Driver Version   : 6.14.10.4299
[I] GUID             : D7B78E66-6432-11CF-5363A121A3C2CB35
[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
[W] D3DContext::InitDevice: sync query not available
[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@e4f972 accelerated=true v
olatile=true
D3DFillRect
D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceScale::ScaledBlit("D3D Surface (render-to-t
exture)", AnyAlpha, "D3D Surface")
> paint took 28946 mikro seconds
D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceScale::ScaledBlit("D3D Surface (render-to-t
exture)", AnyAlpha, "D3D Surface")
> paint took 4846 mikro seconds

when i use BILINEAR interpolation its really fast, tested with my real program, frame time was ~180ms with build05, and is now 5ms with build06

But i think the 945G has some driver bugs? hardware scaling thru D3D texture seems ok

BUT i have one big problem which blow up my hole pc, the gfx card driver stopped working :’(

When i use managed images, the screen gets corrupted and strange things happens, pc reboot, freezing, gfx card driver stopped working, fall back to standard driver.

WM_ERASEBACKGROUND is now using D3D, but why do awt frames use it and Jframes not, when u modify my test16 and subclass test16 from jframe background ist not erased.

A good idea would be to allow us to override default behavior, sun.awt.noerasebackground is not allowed for applets, so i cant use it.

Java using D3D rocks 8)

#55

as far as I know the D3D pipeline will be disabled for the GMA900/950 series starting with build7.

lg Clemens

#56

Yep, that’s the kind of problems we’re seeing with Intel drivers.
They’re pretty bad even for their latest chip (x3100) on Vista,
on XP it’s even worse. By bad I mean driver restart (Vista) or
system reboot (XP) when running d3d apps.

So starting with build b07 the d3d pipeline will be disabled
on Intel chips - at least until they fix these glaring issues in
the drivers.

We could later re-enable it if the driver is newer than certain
version- we already do this kind of check for some ATI boards.

I haven’t looked at that much but I suspect Swing overrides the default
behavior for JFrames to avoid flickering. I think this only become a default recently
(some earlier update of Java 6).

Why is it bothering you though? Do you see any artifacts or something?

Thanks,
Dmitri

#57

just out of curiosity these boards where d3d is disabled, will they switch to ddraw or plain software mode?

#58

There’s no DirectDraw pipeline anymore (there’s no DirectDraw in DirectX9).
They will fall back to sw+gdi rendering.

It shouldn’t be too bad. The main problem with the old DirectDraw pipeline
was that some stuff was done in hw, and some in sw, which caused thrashing
between vram and sysmem, degrading the performance. When everything is done
in sw it is not that bad.

Dmitri

#59

Some applets/application and also my applet/application is drawing a backdrop, so first client rect is filled with color then overpainted with backdrop, only for speed reasons ( WM_ERASEBACKGROUND was done using GDI in previous release, i think you fixed it in 6uN and its using D3D ), but i think its better to file a RFE for this, its a good feature, so a Window could have a function like setEraseBackground or setOpaque.

It would be very helpfull i we can detect if hardware acceleration is enabled and used, like for me i am drawing a scaled image on the fly and set Image Rendering Hints to NEAREST_NEIGHBOUR, how can i detect that this pc can use hw acceleration when i set Image Rendering Hints to

g2.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);

they idea is to set interpolation to nearest neighbour for all, but for those who have better gfx cards set it to bilinear ( which is much smoother )

with hw acceleration a frame takes 5ms without 200ms, so it would be nice if we get something were we can ask for things like that.

P.S.: i will run my littele Testprogramm test16 on some other pc’s with update6 and give u some feedback about what happened ( surprise surprise )

#60

Hmm. Did you override update() method in your hw component? Because if you didn’t
the default behavior is to clear the background:
http://java.sun.com/products/jfc/tsc/articles/painting/index.html

Yes I agree it would be nice to have some api that would tell you which
operations are accelerated.
Unfortunately it’s hard to come up with something simple and not get
into the whole “capabilities” mess that D3D has, for example.

We do have API to check if Image is “accelerated”, but it’s a bit
confusing since it doesn’t tell which operations to this image (or from it)
are accelerated.

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

Dmitri