do requests for screen painting pile up or does Java know to combine them all into one?
thanks,
dan.
Yes, it combines them up (in Swing, at least - not sure about AWT).
No, it does them asynchronously and whenever it feels like it.
Yes, this means the GUI tends to feel sluggish, and responds in an unpredictable fashion - you can’t ensure that a bunch of stuff appears in a single repaint as this occurs in a thread you have no control over.
No, you don’t want to use this for games, because it will look awful.
What you really want is active rendering, where you draw everything explicitly, when you want to draw it.
Cas 
after reading about volatile images and such, i was under the impression that active rendering is only for full screen exclusive mode. what i’m working on cannot be full screen, must be windowed.
so, am i wrong? if so, pointing me in the right direction would be much appreciated… i.e. a primer, tutorial, etc.
thanks.
you’ve got 2 ways to activly render onto a Component.
component.getGraphics();
which returns you a Graphics context for drawing direct onto the Component. (you’ll have to implement double buffering yourself)
OR
component.createBufferStrategy(numOfBuffers);
// ^^ this creates an optimal buffer strategy
// for bliting onto the Component, and uses the
// number of buffers specified (2 will usually suffice)
BufferStrategy strategy = component.getBufferStrategy();
and then in your render loop, you want something like…
Graphics g = strategy.getDrawGraphics();
// misc render operations
g.dispose();
strategy.show();
incidentally, the process of [quote] combining them up
[/quote]
is coalescing ;). and can be controlled by overriding the method in Component :-
protected AWTEvent coalesceEvents(AWTEvent existingEvent, AWTEvent newEvent)
though its still crap for games even when paint event coalescing has been disabled.
Depending on the game, I think Swing is very well suited t odo it, just because it HAS smart mechanims to perform minimal repaints. And there no reason why it should be ugly, bc. it can look whatever you want to look.
But it is for sure not suitable for 50 repaints a second. I tried it and it just didn’t work out. But if you have very high resolution, multiple layers, much to clip,… I cannot see any reason not to use Swings redraw mechanisms. Take a look at JScrollpane than e.g. - which gives you minimal repaint areas on scrolling.
[quote]Depending on the game, I think Swing is very well suited t odo it, just because it HAS smart mechanims to perform minimal repaints. And there no reason why it should be ugly, bc. it can look whatever you want to look.
But it is for sure not suitable for 50 repaints a second. I tried it and it just didn’t work out. But if you have very high resolution, multiple layers, much to clip,… I cannot see any reason not to use Swings redraw mechanisms. Take a look at JScrollpane than e.g. - which gives you minimal repaint areas on scrolling.
[/quote]
Swing in a game ???
I can draw only 1 conclusion… you are mad ;D
I think we’ll (we’ve) all heard this:
“A game in java ???
I can draw only 1 conclusion… you are mad ;D”
Madness depends on the eye of the one that judges. If the mechanism used does the task, why not?
So, as we are mad anyway, going deeper into madness only matters if we don’t succeed. ;D
[quote]Swing in a game
[/quote]
Swings is not all that bad if your not making a twitch game (something that needs high FPS).
Talking on this subject though, has anyone ever used SWT to create a game or graphical animation? Does SWT render components and events in a seperate thread like the AWT? If I remember right, I seen some code doing event polling manually…
You’re right. SWT doesn’t use a separate thread but uses a dispatch loop that normally is installed in the application’s main thread. As the main thread is idle in most AWT applications, SWT is slightly more efficient here. Like AWT, SWT can only manipulate components in that thread. Unlike AWT, SWT will throw errors if you try to do this from a different thread. This helps catching programming errors.
Rendering is done based on OS callbacks. I can only talk about Windows here. Windows itself has a very efficient way to combine damage rectangles and builds up a damage region (a set of damage rectangles) which is then used to clip the drawings. This all happens outside of Java and directly in the ON_PAINT callback when Windows is in a state for fast damage repair. And custom paint methods are called just once.
With AWT on the other hand, repaint requests are taken from the OS and queued for the AWT event thread. Windows is told that everthing is done and (I’m not sure here) Windows will do its default background painting. Some time later, AWT will combine damage rectangles to a larger damage rectangle, if possible, but has no concept of a damage region which would be more efficient. Instead, it will call all paint methods multiple times for different rectangles which is obviously slower. AWT will explicitely setup a Graphics object somehow connected to a Windows GC and finally the damaged parts of the screen are repainted. This is one reason that AWT and Swing often feel a little bit more sluggish.
Regarding animations, SWT uses DIBs and the GDI bitmap functions but no directX stuff. Therefore, Swing might be faster.
I’m currently creating a tiny freecell-game with SWT and I’m quite satisfied with the drawing speed, it’s okay even without double buffering and it feels a bit faster than AWT. I haven’t tried.
However, I’m only blitting static images. SWT has no concept of image producers or image sources. If you want to create your image by hand, you’d setup an ImageData object which is then converted into a real Image object which can then drawn on a Canvas object. I don’t know how fast this is compared to AWT.
Stefan