Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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 13002 times)
0 Members and 1 Guest are viewing this topic.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Posted 2007-10-03 15:56:24 »


  Hello,

  Sun had released an Early Access of 6uN (formerly known as
  the Consumer Release). You can get b04 here:
    http://download.java.net/jdk6/

  This build contains the new Direct3D 9-based Java2D pipeline,
  which is enabled by default on Windows  platform. It is very similar to the
  OpenGL pipeline (in fact they share a lot of code), and is
  based on Single Thread Rendering model developed for the OpenGL
  pipeline (http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html)

  The D3D pipeline accelerates pretty much the same set of operations
  as the OGL one as well:
    http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html

  So, this is a call to action:
  Please try your applications with this new pipeline and let us know
  if you find any issues.  We really want to make this pipeline rock-solid
  as it needs to be if it is to be left enabled by default. Time is short,
  so the sooner you report issues the better chances are we'll have time
  to fix them.

  Please report both negative and positive findings..

  Take a look at this page for testing/troubleshooting guidelines:
    https://jdk6.dev.java.net/testD3D.html
  You can report issues either on this forum, or on this one
  (which is linked to the java2d-interest mailing list):
   http://forums.java.net/jive/forum.jspa?forumID=69

  There are some known problems in full-screen mode, multi-screen,
  and on some chipsets (namely, Intel 645G). These are being worked on
  and hopefully will be addressed by the release time.

  Another thing to be aware of - this pipeline does not
  accelerate Xor rendering mode. It will be really, really slow.
  Sorry about that.

  Thanks,
    Dmitri
  Java2D Team
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


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

I'm seeing something really strange in JEmu2 after installing this java version.
If I run the applet at http://www.gagaplay.com/jemu2/applet/applet.php?w=640&h=448&driver=outrun with the D3D pipeline enabled, it doesn't draw all frames anymore. It simply skips a lot of frames, resulting in a very choppy display. This doesn't happen using the OpenGL pipeline.

Maybe it is somehow related to how the applet does the rendering:
* The init() method starts a new Thread.
* In the thread, there's a loop which simply does the following:
1  
2  
3  
4  
     emu.refresh(true); // update the emulator for 1 frame, updating the int[] which is backing the backBuffer Image
               backBuffer.flush();
                g.drawImage(backBuffer, (width - (emuWidth * scale)) / 2, (height - (emuHeight * scale)) / 2, emuWidth * scale, emuHeight * scale, null);
                throttle(); // slow down to the correct framerate using Thread.sleep()


I have an Intel Mobile 945GM Express.
I'll see if I can make a small test case.

I hope this helps.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #2 - Posted 2007-10-03 21:35:47 »

Thanks Erik.

May I ask why do you do backBuffer.flush() before the drawImage?

Is backBuffer a VolatileImage or a BufferedImage?

One issue may be that since it is not possible to render directly to
the screen in Direct3D9 we have this emulated mode where
we redirect all on-screen rendering to an off-screen 'buffer strategy-like thingie'
which is then flipped by another thread once in a while. Normally
the update thread wakes up every 100ms, unless you copy a
VolatileImage to the screen, in which case we take it as a
clue that you want to see the results on the screen now.

So the delay you are be seeing could be that.

You can get the best performance by using BufferStrategy instead
of a VI as a back-buffer approach with the D3D/OGL pipelines.

Also, how do Swing apps look on your 945G?
Each Intel chip is full of surprises =)

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

Junior Member





« Reply #3 - Posted 2007-10-04 02:33:25 »

As a clue, the (BufferedImage).flush() is not impl.. So BufferedImage never flushes itself. Solely called from the ImageConsumer , the buffer is cleared when the source is cleared.
As a fact, if your image is Volatile, then nothing will be drawn since the ImageConsumer's have flushed themselves, that is the contract of VolatileImage. But when your Thread sleeps for 100ms, those milliseconds of time ARE LOST indeed, because it could have been time to load further images. That is to Thread an extra process to load up all or part of your buffer concurrently to paint on screen. Then somehow validate your buffer to make the paint method occur when needed.
That has no impact on how you use the pipeline, activated or not, it is thoroughly NOT recommended to flush() your buffer PRIOR to paint, but you may eventually overflow on your heap space if the screen is not well tiled. So TILES are a good solution to make accurate updates on screen. Where Tiles can bring improvements, I ain't focusing the discussion on them, because I don't use them. I prefer to VALIDATE my buffer and to draw only when my buffer is valid and to clear it when it is not valid or overflow is detected. Then the faster the buffer is to load itself, the lesser frames will be skipped. I would say to simply erase any Thread sleeps and to have a variable Timer based on the Swing framework, as the Timer's can be of a variable delay. because 100 ms are a 10 frames per seconds and if you want a 30 FPS then the Timer could vary from 0 - 100ms to regulate rendering events.

That is what I'm talking about, improved double buffering and Thread-safe buffer management (where (Image).flush() must be handled with caution (!)).  The latter of these concepts is left to your own to implement or not. Wink

::::... :..... :::::: ;;;:::™ 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 #4 - Posted 2007-10-04 02:35:01 »

Is there a way to detect, at runtime, if the Direct3D 9 pipeline is enabled? (For example, a system property that can be detected in an Applet's sandbox)

In Milpa (using PulpCore, which uses regular repaint() requests on Windows, and runs at 60fps), I noticed a few dropped frames, but not many. Oddly, I noticed occasional "half-frame" updates - the left side of the applet would occasionally be one frame ahead of the right side. This is on a Mobility Radeon 9600.

When I use -Dsun.java2d.d3d=false, the problem goes away. Without a doubt, the animation looks a lot better with the flag set to false.

I'll try BufferStrategy later to see if there is any difference.
Offline CommanderKeith
« Reply #5 - Posted 2007-10-04 03:46:35 »

Is there a way to detect, at runtime, if the Direct3D 9 pipeline is enabled? (For example, a system property that can be detected in an Applet's sandbox)


Like the opengl pipeline, if you use big T True then it seems to print to standard out if the pipeline is working or not, so try:
-Dsun.java2d.d3d=True

By the way Dmitri, is there any progress on this issue with this bug: 
http://www.java-gaming.org/forums/index.php?topic=14696.0
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378181

The Direct3D pipeline is a great addition by the way!  Cool  It's pretty exciting

Offline broumbroum

Junior Member





« Reply #6 - Posted 2007-10-04 07:48:35 »

in regard to painting on screen, I've some to share if you want some :
there's the rendering scene (actually the std Canvas extended with GraphicsJAI instances) to manage overall painting, both passive and active :
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  
/***/
    Thread screen = null;
   
    /** returns screen refreshing task
     * @return screen refreshing task*/

    protected ActionListener getScreenTask() {
        return new ActionListener() {
           
            public void actionPerformed(ActionEvent pe) {
                final ActionEvent e = pe;
                if (screen instanceof Thread) {
                    if (screen.isAlive()) {
                        return;
                    }
                }
                Thread t = screen = new Thread(vSynch, new Runnable() {
                   
                    public void run() {
                        if (!isDisplayable()) {
                            return;
                        }
                        if (bufferSynch == null) {
                            return;
                        }
                        boolean interrupt_ = false;
                        setIgnoreRepaint(activeRendering);
                        if (activeRendering) {
                            final CoalescedThreadsMonitor monitor0 = bufferSynch;
                            synchronized (monitor0.getMonitor(true)) {
                                monitor0.notifyOnMonitor();
                                if (buffering) {
                                    System.err.println("RenderingScene screen task is waitin' for buffering...");
                                }
                                while (buffering) {
                                    System.err.print(".");
                                    try {
                                        monitor0.waitOnMonitor();
                                    } catch (InterruptedException ex) {
                                        ex.printStackTrace();
                                        Thread.currentThread().interrupt();
                                    }
                                }
                                try {
                                    rendering = true;
                                    doBeforeScreenTasks(e);
                                    System.out.println(((activeRendering) ? "-HARD RENDERING-" : "-SOFT RENDERING-") + "\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\screen initied - " + System.currentTimeMillis());
                                    BufferStrategy strategy = RenderingScene.this.getBufferStrategy();
                                    Graphics g = null;
                                    do {
                                        do {
                                            g = strategy.getDrawGraphics();
                                            if (g != null) {
                                                Rectangle box = new Rectangle(0, 0, getWidth(), getWidth());
                                                g.setClip(box);
                                                g.clearRect(box.x, box.y, box.width, box.height);
                                                draw(g, RenderingScene.this);
                                                g.dispose();
                                            }
                                        } while (strategy.contentsRestored());
                                        if (isDisplayable()) {
                                            strategy.show();
                                        }
                                    } while (strategy.contentsLost());
                                    doAfterScreenTasks(e);
                                } catch (InterruptedException e) {
                                    e.printStackTrace();
                                    interrupt_ = true;
                                } finally {
                                    rendering = false;
                                }
                            }
                            final CoalescedThreadsMonitor monitor1 = vSynch;
                            synchronized (monitor1.getMonitor(false)) {
                                monitor1.notifyAllOnMonitor();
                            }
                            if (interrupt_) {
                                Thread.currentThread().interrupt();
                            }
                        } else {
                            repaint();
                        }
                    }
                }, "T-screen-refresh");
                t.setPriority(Thread.MAX_PRIORITY);
                t.setDaemon(false);
                t.start();
            }
        };
    }
The actionListener is then sent to a Swing Timer that makes the event occur every 10ms if possible or skip.

::::... :..... :::::: ;;;:::™ 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 #7 - Posted 2007-10-04 07:57:37 »

What I mean is, is there a way to programmatically detect, at runtime, if the D3D9 pipeline is used?

If so, for existing games, at runtime the engine can use new code (using BufferStrategy) on the D3D9 pipeline, but stick with the old code (repaint()) on other pipelines (which I know already works fine on Java 1.4, Java 1.5, and the current Java 6 on Windows, on a wide variety of hardware).

Because if I had to switch to using new rendering code for all Java VMs, that creates a lot of QA work. So right now I only want to switch to new rendering code if the user has the D3D9 pipeline. (The alternative is to "guess" the VM is using D3D9 by checking if the version number is 1.6.0_05 - hairy stuff.)

BTW, I'm really bummed about non-accelerated Xor rendering  Grin
Offline CommanderKeith
« Reply #8 - Posted 2007-10-04 12:22:30 »

in regard to painting on screen, I've some to share if you want some :
there's the rendering scene (actually the std Canvas extended with GraphicsJAI instances) to manage overall painting, both passive and active :

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?

What I mean is, is there a way to programmatically detect, at runtime, if the D3D9 pipeline is used?

Maybe this will work (I don't have a jdk on this computer to make sure):  System.getProperty("Dsun.java2d.d3d");


Offline CommanderKeith
« Reply #9 - Posted 2007-10-04 12:31:17 »

Is backBuffer a VolatileImage or a BufferedImage?

One issue may be that since it is not possible to render directly to
the screen in Direct3D9 we have this emulated mode where
we redirect all on-screen rendering to an off-screen 'buffer strategy-like thingie'
which is then flipped by another thread once in a while. Normally
the update thread wakes up every 100ms, unless you copy a
VolatileImage to the screen, in which case we take it as a
clue that you want to see the results on the screen now.

So the delay you are be seeing could be that.

You can get the best performance by using BufferStrategy instead
of a VI as a back-buffer approach with the D3D/OGL pipelines.
Hi Dmitri, why does this update thread only wake up every 100ms?  That only 10FPS.  Of course I'm sure that you've investigated, but why do we need this intermediating update thread for D3D, we didn't have it in the old pipeline and I assume that non-java D3D apps don't have it. 

Thanks,
Keith

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

Senior Member


Medals: 1


Java games rock!


« Reply #10 - Posted 2007-10-04 13:16:31 »

Great to see the improvements made to the D3D pipeline. however its a bit dangerous in my mind to release it that shortly before the targeted release of the consumer-jvm. I'll test all my apps to see whats happening...
I always dreamed the OpenGL pipeline would be default on windows and all drivers would have to be compatible Wink
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2007-10-04 15:10:56 »

Is there a way to detect, at runtime, if the Direct3D 9 pipeline is enabled? (For example, a system property that can be detected in an Applet's sandbox)


Unfortunately there isn't. As of now the sun.java2d.d3d property is set to 'true' by default
and you can check it but it doesn't guarantee that the pipeline is enabled.

Another clue is to check if the GraphicsConfiguration's Buffer and Image Capabilities
say that they're accelerated (see GraphicsConfiguration.getImageCapabilities()).

But this one will also return true if the older DirectDraw pipeline is enabled..

Quote
In Milpa (using PulpCore, which uses regular repaint() requests on Windows, and runs at 60fps), I noticed a few dropped frames, but not many. Oddly, I noticed occasional "half-frame" updates - the left side of the applet would occasionally be one frame ahead of the right side. This is on a Mobility Radeon 9600.

Yes, this is likely the same screen update issue. If the application just renders directly to
the screen (not even using a back-buffer),  there is no way for us to tell when
it's a good time to flip the fake screen surface.

Doing animations without a back-buffer - directly to the screen - is typically not a good idea.

Anyway, we might want to decrease the update thread sleep to 50ms - that should
improve the situation somewhat.

But the real fix is to use BufferStrategy going forward..

Quote
When I use -Dsun.java2d.d3d=false, the problem goes away. Without a doubt, the animation looks a lot better with the flag set to false.

I'll try BufferStrategy later to see if there is any difference.

Please let us know how it goes.

Thanks,
  Dmitri

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #12 - Posted 2007-10-04 15:16:14 »

What I mean is, is there a way to programmatically detect, at runtime, if the D3D9 pipeline is used?

If so, for existing games, at runtime the engine can use new code (using BufferStrategy) on the D3D9 pipeline, but stick with the old code (repaint()) on other pipelines (which I know already works fine on Java 1.4, Java 1.5, and the current Java 6 on Windows, on a wide variety of hardware).

Because if I had to switch to using new rendering code for all Java VMs, that creates a lot of QA work. So right now I only want to switch to new rendering code if the user has the D3D9 pipeline. (The alternative is to "guess" the VM is using D3D9 by checking if the version number is 1.6.0_05 - hairy stuff.)

Yes, relying on java version stuff would not be a good idea, for sure.
Sorry, I don't have an answer for you.

We'll try to tweak the on-screen rendering so that the effect is less noticeable,
but unfortunately there's just no way to make it work otherwise - short of
disabling all attempts to accelerate on-screen rendering (or
the image back-buffer to the screen scenario).

Quote

BTW, I'm really bummed about non-accelerated Xor rendering  Grin


I understand. Say 'thanks' to the dudes who designed Direct3D =)
We'll try to work out something, but so far it doesn't look good.

As a workaround we may disable accelerated rendering  for surfaces where xor rendering is
detected. The current approach is so slow that it's not really usable anyway.

Thanks,
  Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #13 - Posted 2007-10-04 15:18:28 »

That is what I'm talking about, improved double buffering and Thread-safe buffer management (where (Image).flush() must be handled with caution (!)).  The latter of these concepts is left to your own to implement or not. Wink

Flush() is really to be used only when you think you're done with the image.
Like if you're loading a new level, old sprite images can be flushed to speed up
vram recovery.

I can not think of why one would flush the back-buffer, though.

Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #14 - Posted 2007-10-04 15:24:05 »

Hi Dmitri, why does this update thread only wake up every 100ms?  That only 10FPS.  Of course I'm sure that you've investigated, but why do we need this intermediating update thread for D3D, we didn't have it in the old pipeline and I assume that non-java D3D apps don't have it. 

Thanks,
Keith

Because like I said, there is no way in Direct3D 9 to render directly to the screen.
You can not copy images to the screen either.

But we thought that most active rendering games at least use some kind of
back-buffer (the thought was that it would typically be a VolatileImage).
So we have a special case for when application copies a VI to the screen
(which is redirected to our back-buffer surface) - the update thread is
waken up immediately so if you use a VI as your back-buffer you should
not see much of a difference (well, we still do one extra step - flip the
back-buffer surface).

We can make the same optimization for copying BufferedImages to the
screen - I guess many people still use BufferedImages for their back-buffers.
Please let me know if this is  a good idea.

Of course, no native d3d applications have this issue, because none of them
render to the screen. The way all d3d applications work is that they render
to a SwapChain (which is similar to BufferStrategy) and when they're
done with the frame, they Present() it (analog of BufferStrategy.show()).

Thanks,
  Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #15 - Posted 2007-10-04 15:26:39 »


Well, we can not introduce a new API in an update release, so that's out until jdk7.

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.

Thanks,
   Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #16 - Posted 2007-10-04 15:29:24 »

Great to see the improvements made to the D3D pipeline. however its a bit dangerous in my mind to release it that shortly before the targeted release of the consumer-jvm.

I don't get it. This is the consumer JRE (or what used to be known as is). One of the features
is this accelerated pipeline.

I do agree though that it is dangerous to introduce such a change (a new default
rendering pipeline) in what is supposedly just an update release.

Quote
I'll test all my apps to see whats happening...
I always dreamed the OpenGL pipeline would be default on windows and all drivers would have to be compatible Wink

Oh, the dreams, the dreams =)
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #17 - Posted 2007-10-04 15:33:15 »

To sum it up: it looks like we'll need to do some tweaking to our on-screen rendering.

First, we'll probably decrease the update thread sleep time to 50ms, and second,
wake up the update thread immediately (and wait synchronously
while it flips the surface) after any drawImage to the screen - it currently
only does this if a VolatileImage is copied to the screen.

What do you think?

Thanks,
  Dmitri
Offline CommanderKeith
« Reply #18 - Posted 2007-10-04 15:45:10 »

Great, yes immediate wake-up is needed.  By the way, is this checking thread the thread in the Single Threaded Rendering (STR)?  How come the OGL pipeline doesn't need do the 100ms wake-up?

Well, we can not introduce a new API in an update release, so that's out until jdk7.

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.

Thanks,
   Dmitri

Fair enough.  What about another J2D option sun.java2d.vsync=True?!

Thanks for the quick response and great work with the pipeline!

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #19 - Posted 2007-10-04 16:38:40 »

Great, yes immediate wake-up is needed.


You mean, for when a BufferedImage is copied to the screeen? OK. sounds good.

Quote
By the way, is this checking thread the thread in the Single Threaded Rendering (STR)? 
How come the OGL pipeline doesn't need do the 100ms wake-up?

It's not, actually - the "screen updater thread" is a separate thread from the STR
thread - which is the Toolkit thead in the D3D pipeline (we have to use toolkit
thread because of the requirement that some Direct3D operations must be
done on this thread).

The OGL pipeline's STR thread flushes the rendering queue
every 100ms or when a VI->screen copy is detected.

One of the differences is that the operations are 'replayed' when
the queue is flushed in the same order they were done -
as opposed to the D3D case where we may flip the buffer
half-way through the frame -  as some folks noticed.

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)

Thanks,
  Dmitri
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #20 - Posted 2007-10-04 17:15:37 »

Quote
May I ask why do you do backBuffer.flush() before the drawImage?

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.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #21 - Posted 2007-10-04 17:25:37 »

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

Senior Member




If only I knew what I'm talking about!


« Reply #22 - Posted 2007-10-04 18:07:38 »

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

Senior Member


Medals: 1


Java games rock!


« Reply #23 - Posted 2007-10-04 18:31:00 »

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 Smiley

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

Junior Member





« Reply #24 - Posted 2007-10-04 18:51:31 »

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

Senior Member




If only I knew what I'm talking about!


« Reply #25 - Posted 2007-10-04 20:33:10 »

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.

Quote
BTW I was joking about Xor mode. Who uses that, anyway?  Grin

Hehehe..  Well apparently some still do...


Thanks,
Dmitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #26 - Posted 2007-10-04 20:35:45 »

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 Smiley

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.

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

Senior Member


Medals: 1


Java games rock!


« Reply #27 - Posted 2007-10-04 21:47:35 »

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

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #28 - Posted 2007-10-05 08:53:04 »

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.

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

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #29 - Posted 2007-10-05 15:35:06 »

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.

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

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!