Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Please try the new Direct3D 9 pipeline in 6uN EA  (Read 13326 times)
0 Members and 1 Guest are viewing this topic.
Offline broumbroum

Junior Member





« Reply #30 - Posted 2007-10-06 10:48:42 »

Hi again !
Thanks.  Even after studying the code I'm not quite sure how it acts to sync painting with the screen refresh... is it somehow using the BufferStrategy to find out when the screen's ready to paint?

Maybe this will work (I don't have a jdk on this computer to make sure):  System.getProperty("Dsun.java2d.d3d");
synch painting with the screen refresh means that the screen is painted before it is refreshed, isn't it? Then figure out a scheme that can wait for the painting before to refresh and vice-versa !
That's a one-to-one relationship on the BufferStrategy context and the BufferedImage. That is yet implemented throughout the (BufferStrategy).contentsLost() and the MediaTracker resp.. That makes 2 steps already.
The last step is to synch' from those 2 steps to bring out a simple post-get process. This is done with 2 monitors and 2 "bool-switches".

To synthetize the whole, the offscreen BufferedImage (I called it the Sprite) must be tracked with a MEdiaTRacker instance, while the BufferStrategy is repainted if its contents get lost (this common check loop is retrieved from the BufferStrategy JavaDoc 1.6) and when the Sprite is fully loaded I switch a boolean buffering from true to false while the screen refreshing thread waits on a first monitor to get notified of the buffering value. This check is done reversed while the refreshing is done, see that a refreshing boolean-switch is used, as well. Solely when this respective check is OK, we can observe a synch'ed buffer-to-screen process.

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline brackeen

Junior Member





« Reply #31 - Posted 2007-10-07 00:09:16 »

Quote
I could easily make all BufferStrategies vsync-ed (including our "fake onscreen" one) -
right now they're v-synced only in full-screen mode. But that would really mess up
applications  which don't expect to be throttled.

On Mac OS X, the BufferStrategy is v-synced and throttled in the Java Plug-in . So developers doing cross-platform applet games are already expecting to be throttled.

Throttling applets makes sense, since in a browser environment it is overkill to run higher than the monitor refresh rate or use too much processor than necessary. Plus, for casual games, it looks better.

So hey, if you wanted to turn on v-syncing in applets, I'd be thrilled!
Offline CommanderKeith
« Reply #32 - Posted 2007-10-16 08:14:44 »

Hi Dmitri,

How's the pipeline going?!  I'd love to read something about it or try the next build.  Exciting times!  Cool

Quote
Fair enough.  What about another J2D option sun.java2d.vsync=True?!
We're trying to avoid adding more flags. Also, the flag won't help
applets and webstart apps (unless we make it public and
add to the list of 'secured' flags)


On this subject, what are the chances that one day we will be able to programatically choose the pipeline in our code after Web Start has begun?  Since web start uses the VM before our code gets a chance it sets the which graphics pipeline is going to be used unless we specify it as a VM flag.  In the future will it be possible to switch pipelines half-way through the program's execution?

Thanks,
Keith

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #33 - Posted 2007-10-16 16:00:03 »

Quote
How's the pipeline going?!  I'd love to read something about it or try the next build.  Exciting times! 

It's going well, but there's still tons of stuff to be done.
There weren't many fixes in b05, but there's a bunch in b06,
including the on-screen rendering responsiveness fix. I'm
not sure which build they'll put out on java.net.

Regarding switching the pipelines - we thought about it, but at this point
it can't be done w/o adding new API.

One thing that would help is the out of process plugin project.
It will allow to set the VM parameters in the applets - they'll
be executed in a separate VM. I presume the same will work
for webstart apps. I think it is being targeted for 6uN as well.

As for switching half-way, again - we'll need some kind of API for that.
There's nothing technically impossible here - at least for the d3d
pipeline we have to shut it down/restart during the runtime
for some cases anyway, so the code is already there.

Dmitri
Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #34 - Posted 2007-10-16 20:25:16 »

One thing that would help is the out of process plugin project.
It will allow to set the VM parameters in the applets - they'll
be executed in a separate VM. I presume the same will work
for webstart apps. I think it is being targeted for 6uN as well

Sad that I never read more about the "out-of-process plugin", I guess it works the same way as the Mozilla-Plugin on Unix?
Does this mean system-access again even when running in IE7 on Vista?

Thank you in advance, lg Clemens
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #35 - Posted 2007-10-18 18:04:43 »

Sad that I never read more about the "out-of-process plugin", I guess it works the same way as the Mozilla-Plugin on Unix?
Does this mean system-access again even when running in IE7 on Vista?

Thank you in advance, lg Clemens

Here Ken Russel reveals some details about the new plugin:
  http://ajaxian.com/archives/ken-russell-on-the-new-java-plugin

Dmitri
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #36 - Posted 2007-10-18 18:49:36 »

transcript anyone? - the background noise is killing me!
but from what I could gather, this looks like a very very interesting thing! looking forward to it!!

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #37 - Posted 2007-10-20 13:44:56 »

with the new java plugin is it possible to send parameters to applets like "-Dsun.java2d.d3d=false" ?

also wondering if there are any issues running JOGL/LWJGL applets and if they are still compatible with the d3d turned on?
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #38 - Posted 2007-10-21 01:34:25 »

with the new java plugin is it possible to send parameters to applets like "-Dsun.java2d.d3d=false" ?

  Yes, that's the idea.

Quote
also wondering if there are any issues running JOGL/LWJGL applets and if they are still compatible with the d3d turned on?

  Yes, it will work. First, you should be able to just speficy d3d=false (see above), and secondly,
  I believe Ken was working on something that would just disable the d3d pipeline
  during jogl initialization.
  The d3d pipeline can be disabled even after it was initialized,
  it will release all d3d resources and unload d3d9.dll ..

  Dmitri
   
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #39 - Posted 2007-10-21 05:28:18 »

awesomeness! anything that will make opengl in applets possible in a commercial context is a very good thing!
The current unstableness of opengl applets - and sometimes plain applets - leaves something to desire  Undecided
of course we'll have to wait 834920 years before apple has their implementation updated Sad

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #40 - Posted 2007-10-31 03:35:48 »

@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  Shocked (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

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



Offline DzzD
« Reply #41 - Posted 2007-10-31 08:50:29 »

Quote
This build contains the new Direct3D 9-based Java2D pipeline,
  which is enabled by default on Windows  platform


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.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #42 - Posted 2007-10-31 17:21:45 »

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

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 .

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

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

Quote

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


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.

Quote
this is output from trace J2D_TRACE_LEVEL=5

CheckAdaptersInfo
------------------
Adapter Ordinal  : 0
Description      : Intel(R) 82945G Express Chipset Family
GDI Name, Driver : \\.\DISPLAY1, igxprd32.dll
Vendor Id        : 0x8086
Version          : 6.14.10.4764
------------------

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.

Quote

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  Smiley


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

Thanks,
  Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #43 - Posted 2007-10-31 17:31:00 »


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.

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

Senior Member


Medals: 1


Java games rock!


« Reply #44 - Posted 2007-11-01 12:43:33 »

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 Smiley
Thanks a lot!

lg Clemens
Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #45 - Posted 2007-11-01 13:35:28 »

@trembovetski

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

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


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  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
/**************************************************************************************************
 *
 *************************************************************************************************/


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

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

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

Happy Halloween :-)
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #46 - Posted 2007-11-01 18:37:11 »

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

  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.

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

  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.

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

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

Quote
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 Smiley
Thanks a lot!

lg Clemens

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

Senior Member




If only I knew what I'm talking about!


« Reply #47 - Posted 2007-11-01 20:13:17 »


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:
1  
2  
3  
4  
D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface")
> paint took 852 mikro seconds


Without the tracing:
1  
2  
3  
4  
> 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.

@trembovetski

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

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

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.

Quote

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 )

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.

Quote

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.

Quote
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

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

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)
1  
2  
3  
        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:
1  
2  
3  
D3DFillRect
D3DDrawGlyphs
sun.java2d.d3d.D3DRTTSurfaceToSurfaceTransform::TransformBlit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface")


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

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

Quote
Happy Halloween :-)

Boo! =)

Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #48 - Posted 2007-11-01 21:44:44 »

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

Dmitri
Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #49 - Posted 2007-11-02 15:56:34 »

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

Dmitri


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 )

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  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
[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(TM) SE Runtime Environment (build 1.6.0_05-ea-b05)
Java HotSpot(TM) Client VM (build 1.6.0_05-ea-b05, mixed mode, sharing)

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

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.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #50 - Posted 2007-11-02 18:34:29 »

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

Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #51 - Posted 2007-11-03 05:43:16 »

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

Junior Member





« Reply #52 - Posted 2007-11-04 02:14:08 »

Quote
FYI: build b06 is out:
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!

Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #53 - Posted 2007-11-05 19:22:21 »

running test16.java with build06

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

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  Cool

Offline Linuxhippy

Senior Member


Medals: 1


Java games rock!


« Reply #54 - Posted 2007-11-05 20:02:29 »

Quote
But i think the 945G has some driver bugs?
as far as I know the D3D pipeline will be disabled for the GMA900/950 series starting with build7.

lg Clemens
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #55 - Posted 2007-11-06 18:01:49 »

running test16.java 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  Cry

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.

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.

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

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

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


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

Thanks,
   Dmitri
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #56 - Posted 2007-11-06 19:05:35 »

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

Senior Member




If only I knew what I'm talking about!


« Reply #57 - Posted 2007-11-06 22:03:57 »

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

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

Junior Member




why does the chicken cross the road?


« Reply #58 - Posted 2007-11-08 16:38:04 »

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

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

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 )
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #59 - Posted 2007-11-08 17:41:04 »

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.

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

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

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
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (25 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (39 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!