Skip to main content

VolatileImage.validate() does not (always) work

31 replies [Last post]
kiamur
Offline
Joined: 2006-11-10

Hi,

I have a VolatileImage as backbuffer for my graphic. This graphic is placed in a dialog which can be moved by the user from one screen to the other.

Each time before I render my graphic into that memory, I start a viBackbuffer.validate(this.getGraphicsConfiguration) command. This works fine on my development system (. Each time the dialog moves to an other screen, I create a message on the console that validate() found a new environment and creates a new compatible backbuffer.
On the machine where the app has to run, it appears (quite often) that the validate call does not recognize that the backbuffer is located on an other screen. I have to drag the dialog several times from one screen to the other until validate() gets it.

I use JRE6 update 10 b25 on both machines as runtime. The development system runs a Pentium D 3.2GHz, 1GB RAM, Geforce 7600GS, WinXP SP2. The other machine is a Pentium M 1,8GHz, 1GB RAM, ATI Mobility Radeon 9000.

Is there something I can do to make validate a reliable call?

Thanks,
Maik

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kiamur
Offline
Joined: 2006-11-10

Okay, when I decide to use "active rendering" in windowed mode, do I get hardware acceleration as well? I just surfed a little bit through the net regarding this topic and read here http://www.gamedev.net/reference/programming/features/javarender/page2.asp , that this attempt uses blitting in windowed mode. That is exactly what I wanted to avoid because in the beginning of my coding, I used BufferedImages and got 100% CPU usage because the transfering of the image from main memory to the graphics card (-> the blitting) was so cost expensive.

Maybe i didn't get this issue right here, because after all that what I already tried and all the different possibilities, I am very confused . .. .

If I would be in fullscreen mode and could use page flipping, that would be an alternative if not my accelerated memory on my graphics card would be so limited (-> 64MB). Page flipping would mean, that I have to allocate twice the size of my image in memory, right? You have to remember, that there are some more backbuffers for our old images that have to be stored in that memory, too.
After exprimentationing and testing the whole day, today, I got to the point that my biggest problem is exactly this limited VRAM memory . . . . .
Especially because it is very frustrating, that the memory is lockked a long time after an image had been disposed (I hoped that VolatileImage.flush() would have helped that problem, but it does not really . . .).

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Okay, when I decide to use "active rendering" in windowed mode, do I get hardware acceleration as well?
> I just surfed a little bit through the net regarding this topic and
> read here http://www.gamedev.net/reference/programming/features/javarender/page2.asp ,
> that this attempt uses blitting in windowed mode. That is exactly what I
> wanted to avoid because in the beginning of my coding, I used BufferedImages
> and got 100% CPU usage because the transfering of the image from main memory to the graphics card (-> the blitting) was so cost expensive.

Yes, you will get hw acceleration. You seem to be identifying blitting with
lack of hardware acceleration. Blit is just an operation, it can be hw
accelerated or not. In this case it will be. In windowed mode
when you copy back-buffer to the screen (whether it's a VolatileImage or
BufferStrategy), at the native level somewhere there's a blit (since you
can't generally do a 'flip' in windowed mode.

>
> Maybe i didn't get this issue right here, because after all that what I already tried and all the different possibilities, I am very confused . .. .
>
> If I would be in fullscreen mode and could use page flipping, that would be an alternative if not my accelerated memory on my graphics card would be so limited (-> 64MB). Page flipping would mean, that I have to allocate twice the size of my image in memory, right? You have to remember, that there are some more backbuffers for our old images that have to be stored in that memory, too.
> After exprimentationing and testing the whole day, today, I got to the point that my biggest problem is exactly this limited VRAM memory . . . . .
> Especially because it is very frustrating, that the memory is lockked a long time after an image had been disposed (I hoped that VolatileImage.flush() would have helped that problem, but it does not really . . .).

I don't see why you would use any more memory with one
approach vs the other.

Thanks,
Dmitri

> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291707
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

> You seem to be identifying blitting with lack of hardware acceleration.

Well, yes . . . .
Some time ago I found this site on the net: http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcrua.html

There it is said that "Any time you see a MaskBlit or any of the General* primitives, it typically means that some of your rendering is going through software loops."
Now, my understanding of all the "behind the scenes" stuff is not that great, so I assumed, that every time there is blitting involved, it has something to do with software instead of hardware . . . .

> I don't see why you would use any more memory with one approach vs the other.

I thought, if I have two "pages" between whom I "flip" then I must have twice the memory for one graphic in VRAM.
On the other side, I thought that with the backbuffer method I only have one image (in my case the volatile type) in VRAM on which I render, and after the rendering is finished, I put that on the screen . . . .

You see, I dig around a lot and maybe there are many wrong thoughts in my mind. But all in all you help a lot to bring some things in a straight line. I would like to read a lot more about the stuff that happens in the background. I mean the stuff that goes beyond the Java2D framework (-> hardware acceleration and how it works. . .). can you suggest some literature for me?!?

Up to now, thank you very much for your support!

Besides that all, I haven't figured out a real solution for the problem this thread initially started with, but I am on a good way to reconstruct our old fashioned graphics library in order to let it use VolatileImages, too, and the performance is getting better every day . . . .

Maik

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> You seem to be identifying blitting with lack of hardware acceleration.
>
> Well, yes . . . .
> Some time ago I found this site on the net: http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gcrua.html
>
> There it is said that "Any time you see a MaskBlit or any of the General* primitives, it typically means that some of your rendering is going through software loops."
> Now, my understanding of all the "behind the scenes" stuff is not that great, so I assumed, that every time there is blitting involved, it has something to do with software instead of hardware . . . .

I see.
There's a difference between MaskBlit, Blit and say D3DBlit.

When investigating performance issues you look at the primitives
being used (blits are one of them) and make sure that you have
as many "accelerated" ones (those with D3D prefix on windows)
as possible.

>> I don't see why you would use any more memory with one approach vs the other.
>
> I thought, if I have two "pages" between whom I "flip" then I must have twice the memory for one graphic in VRAM.
> On the other side, I thought that with the backbuffer method I only have one image (in my case the volatile type) in VRAM on which I render, and after the rendering is finished, I put that on the screen . . . .

Well, with flipping one page is the "screen" (front buffer), another is the
back-buffer. During the flip the ponters to those are swapped.

But in the non-flipping situation you'd still have the the front-buffer,
it won't just disappear - this is the memory the graphcis chip scans
when sending it to your monitor.

The only difference is in the method
of transferring the data from back-buffer to the front buffer.
With Blitting the data is copied. But the amount of vram used
is the same in both cases.

Thanks,
Dmitri

>
> You see, I dig around a lot and maybe there are many wrong thoughts in my mind. But all in all you help a lot to bring some things in a straight line. I would like to read a lot more about the stuff that happens in the background. I mean the stuff that goes beyond the Java2D framework (-> hardware acceleration and how it works. . .). can you suggest some literature for me?!?
>
> Up to now, thank you very much for your support!
>
> Besides that all, I haven't figured out a real solution for the problem this thread initially started with, but I am on a good way to reconstruct our old fashioned graphics library in order to let it use VolatileImages, too, and the performance is getting better every day . . . .
>
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291964
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

markgrantham
Offline
Joined: 2006-09-13

Maik,

The Timer which you are using is a java.util.Timer (not a javax.swing.Timer), so your rendering function is not being called on the Event Dispatch Thread. This could be why you are not always getting the GraphicsConfiguration / GraphicsDevice which you expect (as getGraphicsConfiguration() must be called from the EDT).

In my application, I keep the current GraphicsConfiguration as a volatile instance variable, and update it when the form moves (in the same way as Dmitri's test application). My rendering loop (which runs in its own thread) then reads this value.

Hope this helps

Mark

kiamur
Offline
Joined: 2006-11-10

Hi Mark,

thanks for your tips.

Now, I use the swing timer and do the checking for the graphics configuration when my frame moves. Both actions do not help my problem. It still occurs randomly that it is not realized that the dialog and the nested image are on a different screen . . . .

Maik

markgrantham
Offline
Joined: 2006-09-13

Maik,

Can you please show the code where you detect the changed GraphicsConfiguration? Is it in the top level window (JFrame / JWindow etc) of your application?

Mark

kiamur
Offline
Joined: 2006-11-10

Hi Mark,

Because our software is a huge project with many packages, it is not that easy . . .

The graphic I'am talking about is nested in one of our own dialog classes. This dialog can be made of of different container types. In my case this type is a JFrame. So i added this code to the constructor of this dialog:

gc = this.getView().getGraphicsConfiguration();

this.getView().addComponentListener(new ComponentAdapter()
{
public void componentMoved(ComponentEvent e)
{
if (e.getComponent().getGraphicsConfiguration() != gc)
{
System.out.println("Moved!!");
gc = e.getComponent().getGraphicsConfiguration();
controlPanel.getDisplayPanel().setGraphicsConfiguration(gc);
}
}
});

The line "controlPanel.getDisplayPanel().setGraphicsConfiguration(gc);" sets the current graphics configuration in my displayPanel where the VolatileImage is actually rendered.
This attempt works as good (or bad) as the checking for the current graphics configuration directly in the displayPanel object. . . .

Maik

(besides, can someone tell me what code tags I have to use in this forum?)

Dmitri Trembovetski

Ugh. Please don't attempt to cache or track
your GraphicsConfiguration.

It will be updated for you when the window is moved.
You are supposed to retrieve it every time from the
component.

The test I sent the other day was just an illustration and
quick verification test, not really to be used in production.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hi Mark,
>
> Because our software is a huge project with many packages, it is not that easy . . .
>
> The graphic I'am talking about is nested in one of our own dialog classes. This dialog can be made of of different container types. In my case this type is a JFrame. So i added this code to the constructor of this dialog:
>
> gc = this.getView().getGraphicsConfiguration();
>
> this.getView().addComponentListener(new ComponentAdapter()
> {
> public void componentMoved(ComponentEvent e)
> {
> if (e.getComponent().getGraphicsConfiguration() != gc)
> {
> System.out.println("Moved!!");
> gc = e.getComponent().getGraphicsConfiguration();
> controlPanel.getDisplayPanel().setGraphicsConfiguration(gc);
> }
> }
> });
>
> The line "controlPanel.getDisplayPanel().setGraphicsConfiguration(gc);" sets the current graphics configuration in my displayPanel where the VolatileImage is actually rendered.
> This attempt works as good (or bad) as the checking for the current graphics configuration directly in the displayPanel object. . . .
>
> Maik
>
> (besides, can someone tell me what code tags I have to use in this forum?)
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=292252
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

markgrantham
Offline
Joined: 2006-09-13

Dmitri,

I have my rendering code in a separate thread for performance, so I cache the GraphicsConfiguration so that it can access it in a thread safe way.

Is there a better way of doing this? Or can I just get the GraphicsConfiguration from the component from a thread other than the EDT?

Thanks

Mark

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Dmitri,
>
> I have my rendering code in a separate thread for performance, so I cache the GraphicsConfiguration so that it can access it in a thread safe way.
>
> Is there a better way of doing this? Or can I just get the GraphicsConfiguration from the component from a thread other than the EDT?

Yes. Never cache graphics configuration. It may change at any time,
even without component moving. It is safe to call
Component.getGraphicsConfiguration() from any thread (AWT is thread-safe).

Thanks,
Dmitri

>
>
> Thanks
>
> Mark
> [Message sent by forum member 'markgrantham' (markgrantham)]
>
> http://forums.java.net/jive/thread.jspa?messageID=292505
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi again,

so Dmitri, you would suggest to get the current graphics cinfiguration each time I touch the according image, right. That was the approach I used at the very beginning (as i have shown in one of my code examples here). But still, I have the problem that the call sometimes does not react to a changing graphics configuration on my target system. I assume that you have no idea what to do about that, right.

One more thing to say: When the dialog with the volatileImage in it was moved to the other screen, but the graphics configuration change was not recognized, the CPU load increases immediately. . . -> This leads me to the conclusion, that the image is no more hardware accelerated and that is exactly what I want to avoid.

Could it be that somewhere in the background a method is called (in order to get the current graphics configuration) that returns immediately, no matter if the system was able to detect the current configuration or not, and that when the method returns, it returns the same configuration as the last time due to a cached field or something? I am just wondering, how I can solve this problem because the enduser would not understand, why his system slows down sometimes he moves the dialog to an other screen and sometimes it does not slow down . . . .

Maik

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Hi again,
>
> so Dmitri, you would suggest to get the current graphics cinfiguration each time I touch the according image, right. That was the approach I used at the very beginning (as i have shown in one of my code examples here). But still, I have the problem that the call sometimes does not react to a changing graphics configuration on my target system. I assume that you have no idea what to do about that, right.

I don't. If you can boil this down to a simple example, please
file a bug against AWT.

> One more thing to say: When the dialog with the volatileImage in it was moved to the other screen, but the graphics configuration change was not recognized, the CPU load increases immediately. . . -> This leads me to the conclusion, that the image is no more hardware accelerated and that is exactly what I want to avoid.
>
> Could it be that somewhere in the background a method is called (in order to get the current graphics configuration) that returns immediately, no matter if the system was able to detect the current configuration or not, and that when the method returns, it returns the same configuration as the last time due to a cached field or something? I am just wondering, how I can solve this problem because the enduser would not understand, why his system slows down sometimes he moves the dialog to an other screen and sometimes it does not slow down . . . .

This might happen but only for one frame. The next time you call
getGraphicsConfiguration it should return the new GC. If that doesn't
happen it's a bug. Like I said, if you can produce a simple test case
which reproduces the problem, file a bug.

My test case worked fine as you had seen. You can change it to
behave more like your application - instead of waiting on windowmove
event and update the GC then have a loop in some thread
which retrieves and prints the gC (or updates the title of the frame).

Thanks,
Dmitri

>
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=293203
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

I don't see much wrong with the code.
See comments below.

java2d@JAVADESKTOP.ORG wrote:
> Okay, so here is my code. Nothing special, I guess . . . .
>
> // Render Frame to volatile image.
> do
> {
> // Check if the viBackbuffer is still valid.
> graphicsConfiguration = this.getGraphicsConfiguration();

This graphicsConfguration field, are you sure it's not accessed
(set) from some other thread?

Also, could you print it out and see if it changes when you move
the frame from one screen to another.

Thanks,
Dmitri

> valCode = viBackbuffer.validate(graphicsConfiguration);
>
> if (valCode == VolatileImage.IMAGE_INCOMPATIBLE)
> {
> System.out.println("Image Incompatible . . . . ");
> System.out.println("Display Panel - Memory: " + graphicsConfiguration.getDevice().getAvailableAcceleratedMemory());
> viBackbuffer.flush();
> viBackbuffer = graphicsConfiguration.createCompatibleVolatileImage(width, height);
> ImageCapabilities ic = viBackbuffer.getCapabilities();
> if (ic.isAccelerated())
> System.out.println("Backbuffer is ACCELERATED!");
> else
> System.out.println("Backbuffer is NOT accelerated . . . ");
> System.out.println("Display Panel - Memory: " + graphicsConfiguration.getDevice().getAvailableAcceleratedMemory());
> // Create graphic2D object from volatile images.
> g2dViBackbuffer = viBackbuffer.createGraphics();
> g2dViBackbuffer.setBackground(Color.white);
>
> // Clear drawing surface of volatile images with color white.
> g2dViBackbuffer.clearRect(0, 0, width, height);
> }
>
> // my render Stuff
>
> } while (viBackbuffer.contentsLost());
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=290852
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi Dmitri,

thanks for your effort!

I will try your code on monday, when I am back at work.

Anyway, to answer the questions from your first answer today:

Firstly, yes, I am sure that no other thread updates my graphicConfiguration field.

The other answer is that meanwhile I do print out the device ID of that field and, as I previously wrote, it does NOT always print out the correct ID on my target system. However, on my development system the same code DOES always print out the correct device ID.
Could this be a performance issue because my target system is significally slower (but in my opinion not too slow) than my development system?

Regards,
Maik

Dmitri Trembovetski

Hi Maik,

Where and how do you get the graphics configuration that you use to
validate the VolatileImage? Could you print it out and see if it
changes when you move the window from one screen to another?

You can also print out the device this GraphicsConfiguration
belongs to. It should change.

Another point is to verify that the VolatileImage is actually
accelerated (using getCapabilities() call). If it's not, it doesn't
need to be recreated when moved from one screen to another.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hi,
>
> I have a VolatileImage as backbuffer for my graphic. This graphic is placed in a dialog which can be moved by the user from one screen to the other.
>
> Each time before I render my graphic into that memory, I start a viBackbuffer.validate(this.getGraphicsConfiguration) command. This works fine on my development system (. Each time the dialog moves to an other screen, I create a message on the console that validate() found a new environment and creates a new compatible backbuffer.
> On the machine where the app has to run, it appears (quite often) that the validate call does not recognize that the backbuffer is located on an other screen. I have to drag the dialog several times from one screen to the other until validate() gets it.
>
> I use JRE6 update 10 b25 on both machines as runtime. The development system runs a Pentium D 3.2GHz, 1GB RAM, Geforce 7600GS, WinXP SP2. The other machine is a Pentium M 1,8GHz, 1GB RAM, ATI Mobility Radeon 9000.
>
> Is there something I can do to make validate a reliable call?
>
> Thanks,
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=290624
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi Dmitri,

as I described in my questioning thread, I get the graphics configuration via "viBackbuffer.validate(this.getGraphicsConfiguration)" whereas viBackbuffer is an VolatileImage object. The expression "this.getGraphicsConfiguration" I found in many documentation for the usage of VolatileImages.
I guess that, as the image is placed in a panel, and the panel is placed in the dialog which is dragged from one screen to the other, the "this"-statement is related to that very panel which is located in the screen device whose graphicsConfiguration is returned. But tomorrow, I will put the return value in the console to verify what it actually is returning.

What I can tell you already today, is that the image IS accelerated. I already do exactly what you suggest and print out the return value of ImageCapabilities.isAccelerated(). And it is always true.

I assume that the validate() method of my viBackbuffer does not recognize that the image is actually in a different screen because I make the ImageCapabilities call in the if-path of validate() when it returns IMAGE_INVALID.

Tomorrow i will post the accordant code section to show you what i exactly do if you don't understand my description, today.

What makes me wonder is the fact that the same code running with the same JRE never fails to recognize the changed screen location on my development system whereas on the target system the failure is almost predictable. . . .

Maik

kiamur
Offline
Joined: 2006-11-10

Okay, so here is my code. Nothing special, I guess . . . .

// Render Frame to volatile image.
do
{
// Check if the viBackbuffer is still valid.
graphicsConfiguration = this.getGraphicsConfiguration();
valCode = viBackbuffer.validate(graphicsConfiguration);

if (valCode == VolatileImage.IMAGE_INCOMPATIBLE)
{
System.out.println("Image Incompatible . . . . ");
System.out.println("Display Panel - Memory: " + graphicsConfiguration.getDevice().getAvailableAcceleratedMemory());
viBackbuffer.flush();
viBackbuffer = graphicsConfiguration.createCompatibleVolatileImage(width, height);
ImageCapabilities ic = viBackbuffer.getCapabilities();
if (ic.isAccelerated())
System.out.println("Backbuffer is ACCELERATED!");
else
System.out.println("Backbuffer is NOT accelerated . . . ");
System.out.println("Display Panel - Memory: " + graphicsConfiguration.getDevice().getAvailableAcceleratedMemory());
// Create graphic2D object from volatile images.
g2dViBackbuffer = viBackbuffer.createGraphics();
g2dViBackbuffer.setBackground(Color.white);

// Clear drawing surface of volatile images with color white.
g2dViBackbuffer.clearRect(0, 0, width, height);
}

// my render Stuff

} while (viBackbuffer.contentsLost());

kiamur
Offline
Joined: 2006-11-10

Hi Dmitri,

I have to apologize to the vaildate() method because it is the "this.getGraphicsConfiguration" that does not always realize that the image is located on a different screen. Now, I make a printout of the device ID each time I call "this.getGraphicsConfiguration" and although the dialoge is on a different screen, the graphic configuration tells me that it is on the old screen. After some more drags from one screen to the other, it finally realises the location change. . . .

Maik

Dmitri Trembovetski

Could you please try this test on that system and see if the
device in the title changes when you move the frame back
and forth.

[code]
import java.awt.Frame;
import java.awt.GraphicsDevice;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

public class GraphicsConfigUpdateTest extends Frame {
private GraphicsDevice currentDevice;
public GraphicsConfigUpdateTest() {
super("GraphicsConfigUpdateTest");
this.addComponentListener(new ComponentAdapter() {
public void componentMoved(ComponentEvent e) {
GraphicsDevice gd =
GraphicsConfigUpdateTest.this.getGraphicsConfiguration().getDevice();
if (gd != currentDevice) {
GraphicsConfigUpdateTest.this.setTitle("Current device: "+
gd.toString());
currentDevice = gd;
}
}
});
setSize(500, 100);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
}

public static void main(String[] args) {
GraphicsConfigUpdateTest test = new GraphicsConfigUpdateTest();
test.setVisible(true);
}
}
[/code]

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hi Dmitri,
>
> I have to apologize to the vaildate() method because it is the "this.getGraphicsConfiguration" that does not always realize that the image is located on a different screen. Now, I make a printout of the device ID each time I call "this.getGraphicsConfiguration" and although the dialoge is on a different screen, the graphic configuration tells me that it is on the old screen. After some more drags from one screen to the other, it finally realises the location change. . . .
>
> Maik

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi Dmitri,

your "Graphics Configuration Update Test" works as expected. The title of the window changes each time it is dragged to an other screen.

So, could it be that the recognition of the current screen device can depend on the overall load of the system? I mean, your test program is very small and should not bother even the slowest system but our software is much more bigger and therefore maybe the system can't provide the right graphics device every time the window is dragged on an other screen. Is this possible?

I think that this might be so because I never have any problems with my code on my development machine. Only on the target system, which is much slower.

Thanks,
Maik

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
> Hi Dmitri,
>
> your "Graphics Configuration Update Test" works as expected. The title of the window changes each time it is dragged to an other screen.
>
> So, could it be that the recognition of the current screen device can depend on the overall load of the system? I mean, your test program is very small and should not bother even the slowest system but our software is much more bigger and therefore maybe the system can't provide the right graphics device every time the window is dragged on an other screen. Is this possible?

To be honest I doubt it. I never seen this happen. But you can
easily test this. Add a little sleep in your rendering loop and
see if it helps on that slow system.

Thanks,
Dmitri

>
> I think that this might be so because I never have any problems with my code on my development machine. Only on the target system, which is much slower.
>
> Thanks,
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291253
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

> To be honest I doubt it. I never seen this happen.
Okay, but what is the explanation for the fact that I NEVER have this problem on the other system although it is 100% the same code? I mean, i don't want to say that my code is without some errors, but it should happen on both machines, if it is code related, right?

> But you can
> easily test this. Add a little sleep in your
> rendering loop and
> see if it helps on that slow system.
I will try that tomorrow . . . .

Thanks, Maik

Dmitri Trembovetski

java2d@JAVADESKTOP.ORG wrote:
>> To be honest I doubt it. I never seen this happen.
> Okay, but what is the explanation for the fact that I NEVER have this problem on the other system although it is 100% the same code? I mean, i don't want to say that my code is without some errors, but it should happen on both machines, if it is code related, right?

There are many reasons why the same code may behave differently
on different systems. Timing issues is one of them (you can get
a deadlock on one system every time, and never on another).

Certainly there's some hw or setup difference that's somehow
affecting the behavior.

Does your rendering loop run on the event dispatch thread
or some other thread?

Thanks,
Dmitri

>> But you can
>> easily test this. Add a little sleep in your
>> rendering loop and
>> see if it helps on that slow system.
> I will try that tomorrow . . . .
>
> Thanks, Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291379
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

>Does your rendering loop run on the event dispatch thread
>or some other thread?

Well, I am not that familiar with the event dispatch thread and myabe that's the problem in my code . . . .

To render my image, which should happen at a fixed rate of 20Hz, I use a Timer which calls my render method in its "scheduleAtFixedRate()" method.
In my render method, I check for the graphicsConfiguration and call the validate() method of my vlatile image. After that, i draw my stuff on the Graphics2D object of the image. Finally, i call the paint()-method (I think it is so, will check that tomorrow at work) of the panel in which the image is situated and let the image be displayed.

I don't know, if all that happens in the event dispatch thread, but I assume it should be, right . . . . ?

Ken Warner

Do you call paint method directly or indirectly through
repaint()?

java2d@JAVADESKTOP.ORG wrote:
>>Does your rendering loop run on the event dispatch thread
>>or some other thread?
>
>
> Well, I am not that familiar with the event dispatch thread and myabe that's the problem in my code . . . .
>
> To render my image, which should happen at a fixed rate of 20Hz, I use a Timer which calls my render method in its "scheduleAtFixedRate()" method.
> In my render method, I check for the graphicsConfiguration and call the validate() method of my vlatile image. After that, i draw my stuff on the Graphics2D object of the image. Finally, i call the paint()-method (I think it is so, will check that tomorrow at work) of the panel in which the image is situated and let the image be displayed.
>
> I don't know, if all that happens in the event dispatch thread, but I assume it should be, right . . . . ?
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291427
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi Ken,

I'm just at work and see that I call it indirectly through repaint().

To be honest, it confuses me a bit that there are the methods repaint(), paint(Grphics g) and even update(Graphics g). I'm sure that I read about the differences and when I have to use one or the other at the time I was first creating my panel, but now, I just don't know anymore the differences and meanings of them . . . .

Maik

Ken Warner

If you call repaint() you invoke the AWT thread and paint()
is called by the AWT thread. update() and paint() should
not be called directly by your program they are generally
called from the AWT thread in response to some sort of
system event like Expose or Move etc.

With VolitileImages, you should render directly from
your program by calling your own render method directly.
Don't call repaint().

Dmitri, did I get that right?

java2d@JAVADESKTOP.ORG wrote:
> Hi Ken,
>
> I'm just at work and see that I call it indirectly through repaint().
>
> To be honest, it confuses me a bit that there are the methods repaint(), paint(Grphics g) and even update(Graphics g). I'm sure that I read about the differences and when I have to use one or the other at the time I was first creating my panel, but now, I just don't know anymore the differences and meanings of them . . . .
>
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291504
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

kiamur
Offline
Joined: 2006-11-10

Hi Ken,

>With VolitileImages, you should render directly from
>your program by calling your own render method directly.
>Don't call repaint().

I do use my own render method, but that method only renders on my background volatile image. After that is finished I somehow have to get my image onto the screen (or to be more precise on my panel). Then, I assume, I have to call repaint() (of the panel) out of my own render method, don't I?

Maik

Dmitri Trembovetski

You can certainly use repaint() with VolatileImages as back buffers.

The alternative approach is called "active rendering", where you
control when stuff gets rendered.

Take a look at this:
http://java.sun.com/docs/books/tutorial/extra/fullscreen/rendering.html

While this is a "full screen" tutorial, the same applies for rendering
in windowed mode.

Also, I reiterate, it is better to use active rendering and BufferStrategy
for double buffering, especially if your application is 'game-like'.

Thanks,
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hi Ken,
>
>> With VolitileImages, you should render directly from
>> your program by calling your own render method directly.
>> Don't call repaint().
>
> I do use my own render method, but that method only renders on my background volatile image. After that is finished I somehow have to get my image onto the screen (or to be more precise on my panel). Then, I assume, I have to call repaint() (of the panel) out of my own render method, don't I?
>
> Maik
> [Message sent by forum member 'kiamur' (kiamur)]
>
> http://forums.java.net/jive/thread.jspa?messageID=291577
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Ken Warner

That's the way I do things. I do active rendering using BufferStrategy.

I turn off repaint() setIgnoreRepaint(true) while I'm active rendering and
then when I'm not active rendering and the applet is just sitting there,
I turn on repaint() with setIgnoreRepaint(false) so that if the applet
gets covered and then re-exposed, it repaints on the screen properly.

My paint() method looks a lot like my active rendering method with slight
differences in the implementation.

I think that way of drawing on the screen is great especially if you
need a high frame rate. Depending on the size of the screen area
rendered to, I can get a frame in less than 100 milliseconds on
my old, slow computer.

The tricky part is trying to get the "look and feel" of the applet
to be constant on computers with much faster graphics and processors.

I try to adjust the amount of drawing by calculating the average number
of frames per second and then adjusting the "movement" of the image.

Lot's of fussy details...

Dmitri Trembovetski wrote:
> You can certainly use repaint() with VolatileImages as back buffers.
>
> The alternative approach is called "active rendering", where you
> control when stuff gets rendered.
>
> Take a look at this:
> http://java.sun.com/docs/books/tutorial/extra/fullscreen/rendering.html
>
> While this is a "full screen" tutorial, the same applies for rendering
> in windowed mode.
>
> Also, I reiterate, it is better to use active rendering and
> BufferStrategy
> for double buffering, especially if your application is 'game-like'.
>
> Thanks,
> Dmitri
>
>
> java2d@JAVADESKTOP.ORG wrote:
>
>> Hi Ken,
>>
>>> With VolitileImages, you should render directly from
>>> your program by calling your own render method directly.
>>> Don't call repaint().
>>
>>
>> I do use my own render method, but that method only renders on my
>> background volatile image. After that is finished I somehow have to
>> get my image onto the screen (or to be more precise on my panel).
>> Then, I assume, I have to call repaint() (of the panel) out of my own
>> render method, don't I?
>>
>> Maik
>> [Message sent by forum member 'kiamur' (kiamur)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=291577
>>
>> ===========================================================================
>>
>> To unsubscribe, send email to listserv@java.sun.com and include in the
>> body
>> of the message "signoff JAVA2D-INTEREST". For general help, send
>> email to
>> listserv@java.sun.com and include in the body of the message "help".
>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".