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.

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 upapplications 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!

We're trying to avoid adding more flags. Also, the flag won't helpapplets and webstart apps (unless we make it public andadd 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?

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'mnot sure which build they'll put out on java.net.

Regarding switching the pipelines - we thought about it, but at this pointit 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'llbe executed in a separate VM. I presume the same will workfor 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 d3dpipeline we have to shut it down/restart during the runtimefor some cases anyway, so the code is already there.

One thing that would help is the out of process plugin project.It will allow to set the VM parameters in the applets - they'llbe executed in a separate VM. I presume the same will workfor 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?

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

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 of course we'll have to wait 834920 years before apple has their implementation updated

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 (D3D pipeline was actived correctly)

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.

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'snot really a d3d blit from VI to the screen there. The D3DBlits are only used whenyou 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 (D3D pipeline was actived correctly)

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

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

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 bydefault, 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 lefton by default. Which is why we have made the early buildsavailable - so that we can catch issues and fix them beforethe release.

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

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

/********************************************************************************************** * is called when parts of the peer are damaged and needs redraw *********************************************************************************************/publicvoidpaint(Graphicsgg) {longstartTime = System.nanoTime();

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 setBackgroundthe 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 byToolkit.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 andif we can specify the interpolation mode ( bilinear would be a great improvement )

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

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

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 - Ialways 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 setBackgroundthe 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 itis just luck.

Basically here's what happens: when we detect that a VI (which is in VRAM) is copiedto 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, whichare extremely slow. And if you don't validate the VI you will never find outthat it is lost.

However, this situation should not have been there in the firstplace. There are only few rare cases where our d3d onscreen supportcould 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 byToolkit.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 andif we can specify the interpolation mode ( bilinear would be a great improvement )

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

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 thrashingbetween vram and sysmem, degrading the performance. When everything is done in sw it is not that bad.

QuoteA 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

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

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 getinto the whole "capabilities" mess that D3D has, for example.

We do have API to check if Image is "accelerated", but it's a bitconfusing 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 areaccelerated.

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