Please try the new Direct3D 9 pipeline in 6uN EA

[erikd]

[quote]May I ask why do you do backBuffer.flush() before the drawImage?
[/quote]
The rendering is done ‘the old way’ : Toolkit.getDefaultToolkit().createImage(MemoryImageSource);
So I need to flush the Image to update it with the newly rendered pixels.

[trembovetski]

FYI: I’ve filed:
6613062: D3D: improve on-screen rendering responsiveness

It should appear on bugs.sun.com in a couple of days.

If you have any other ideas on this - please let me know.

Thanks,
Dmitri

Updated: replied to the wrong post…

[trembovetski]

@erikd

The rendering is done ‘the old way’ : Toolkit.getDefaultToolkit().createImage(MemoryImageSource);
So I need to flush the Image to update it with the newly rendered pixels.

Hmm. I though you just need to do memImageSource.newPixels():
http://java.sun.com/javase/6/docs/api/java/awt/image/MemoryImageSource.html

Thanks,
Dmitri

[Linuxhippy]

@trembovetski

Hmm. I though you just need to do memImageSource.newPixels():
http://java.sun.com/javase/6/docs/api/java/awt/image/MemoryImageSource.html

Is there really no way of fixing such things? Imagine all the old applets relying on some Java2D specifics (may be intentional or not), I am just afraid of all the “it worked, but now doesn’t” publicity on javalobby et al. No dirty tricks inside the new pipeline which could make things like this work?
The delay-shortening and the flush-on-all-drawImage calls seems to be a good tradeof

By the way, are even small XOR-areas a problem, I am using a non-swing toolkit for compatibility with Java-1.1 which uses XOR showing selected areas.

lg Clemens

[brackeen]

Well, I’m not “feeling” 100ms delays (10 frames per second). So it must be doing some sort of wake-up at the moment.

My guess would be it currently wakes up when an AWT repaint event is concluded, but the AWT thread doesn’t wait for the rendering to finish. (This is a guess - I’m thinking outloud here)

BTW I was joking about Xor mode. Who uses that, anyway? ;D

[trembovetski]

@brackeen

Well, I’m not “feeling” 100ms delays (10 frames per second). So it must be doing some sort of wake-up at the moment.

My guess would be it currently wakes up when an AWT repaint event is concluded, but the AWT thread doesn’t wait for the rendering to finish. (This is a guess - I’m thinking outloud here)

There are other events that may cause the thread to wake up so you may be
seeing faster than 100ms updates.

Note that if you do Toolkit.getDefaultToolkit().sync() the update thread will be
waken up.

BTW I was joking about Xor mode. Who uses that, anyway? ;D

Hehehe… Well apparently some still do…

Thanks,
Dmitri

[trembovetski]

@Linuxhippy

Is there really no way of fixing such things? Imagine all the old applets relying on some Java2D specifics (may be intentional or not), I am just afraid of all the “it worked, but now doesn’t” publicity on javalobby et al. No dirty tricks inside the new pipeline which could make things like this work?
The delay-shortening and the flush-on-all-drawImage calls seems to be a good tradeof

As I mentioned, Toolkit.sync() will cause a flush.

We understand that there will be incompatibilities. We’ll try to address them
if we can. But it’s really hard to have it both ways: use modern native
APIs to accelerate some ancient approaches. Somebody will always
be disappointed.

By the way, are even small XOR-areas a problem, I am using a non-swing toolkit for compatibility with Java-1.1 which uses XOR showing selected areas:

It really depends on the area. Currently we just do it pixel by pixel.
The more pixels to cover the slower it will be.

Dmitri

[Linuxhippy]

@trembovetski

We understand that there will be incompatibilities. We’ll try to address them
if we can. But it’s really hard to have it both ways: use modern native
APIs to accelerate some ancient approaches. Somebody will always
be disappointed.

Well of course I understand predicament, and I really appreciate the efforts by Sun to keep Java a alive platform on the desktop.
That said, I guess it has never been more alive than now … great Job done over the past few years. Thanks for such a great platform!

However on the other point of view I see bytecode-transformers for fixing broken bytecodes from old 1.0 and 1.1 days in the Applet-Plugin and a really great effort to stay compatible (which is what makes Sun better than all those opensource runtimes in my opinion).
I don’t know how the compatibility-tests went that were done internally at Sun, but wouldn’t it e.g be possible to make a descision which pipeline should be used depending on the bytecode-target version, maybe with a warning in the Java-Console like “Java2D compatibility pipeline enabled”.
I can’t imagine <= Java-1.3 applets depend on Java2d performance a lot. Ok, I agree this is not elegant either - it seems it can’t solved easily.

Thanks, lg Clemens

[erikd]

@trembovetski

Hmm. I though you just need to do memImageSource.newPixels():
http://java.sun.com/javase/6/docs/api/java/awt/image/MemoryImageSource.html

Thanks,
Dmitri

I’ll see if that makes a difference.
Maybe Image.flush() should wake up the update thread too?
Really I should convert this code to a more modern approach; the applet was like a quick hack and the MemoryImageSource was something I had done before.

We understand that there will be incompatibilities. We’ll try to address them
if we can. But it’s really hard to have it both ways: use modern native
APIs to accelerate some ancient approaches. Somebody will always
be disappointed.

I can appreciate these things might cause incompatibilites. I guess it’s time to deprecate ImageProducer, MemoryImageSource and friends? If they’re not deprecated, I think it’s really important that they will keep working as intended. My vote would go to deprecating them.

[trembovetski]

@erikd

I’ll see if that makes a difference.
Maybe Image.flush() should wake up the update thread too?

I doubt that it would make that much of a difference, but
Image.flush() is intended for releasing the resources associated with the image -
as per the documentation. In 1.1 it would drop the cached pixels so that the next
time you call drawImage ImageConsumer would get the new pixels from the
producer.

So in some way it does achieve what you wanted, but not in a really efficient way
since on every flush it drops all cached buffers instead of just updating
them, etc.

For the “new” image types (BI, VI) - flush() releases vram resources
associated with the image - so if you get into a habit of calling flush()
you’d get some surprises =)

Anyway, what I’m trying to say is that I don’t think flush() should
in any way affect the update thread.

Really I should convert this code to a more modern approach; the applet was like a quick hack and the MemoryImageSource was something I had done before.

I can appreciate these things might cause incompatibilites. I guess it’s time to deprecate ImageProducer, MemoryImageSource and friends? If they’re not deprecated, I think it’s really important that they will keep working as intended. My vote would go to deprecating them.

Here’s a reply on deprecation from Java2D’s Jim Graham:

With regards to deprecation - deprecation was common back in the early
days of 1.1 and even 1.2 when it was new - all APIs that weren’t the
“latest greatest” were deprecated, but it got to a point where
deprecation didn’t really mean much any more. The general philosophy
these days is to deprecate something only if there are specific problems
associated with its use that cannot be worked around.

So we would definitely make sure this stuff works, but not necessarily
in the best way possible - that would require too much effort…

Thanks,
Dmitri

[broumbroum]

Hi again !

@CommanderKeith

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.

[brackeen]

[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.
[/quote]
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!

[CommanderKeith]

Hi Dmitri,

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

@trembovetski

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

[trembovetski]

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

[Linuxhippy]

@trembovetski

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

[trembovetski]

@Linuxhippy

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

[Matzon]

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

[kappa]

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?

[trembovetski]

@kapta

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

Yes, that’s the idea.

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

[Matzon]

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