gl4java-usergroup

[gl4java-usergroup] Re: gl4java-usergroup digest, Vol 1 #105 - 4 msgs

[Stuart F. <st...@de...>]

> I have discover that the multi-threading can slow down the rendering !
> Java may wait before really doing the rendering in the rendering thread,
> and may coalesce rendering. Each frame in my game, i call a rendering,
> but java coalesce them and i have only 1 real rendering for about 30-60
> frames...
Maybe I don't understand your problem, but I don't know if it is related to
multithreading.

Are you calling repaint() once per frame in your game loop and calling
sDisplay() in your paint() (or update()) method?

If so, Java WILL coalesce rendering.

If this describes your situation, call sDisplay() instead of repaint() in
your game loop.

Simple example:

public class Game extends GLCanvas implements Runnable {
  boolean gameOver = false;

  public void run() {
    while(!gameOver) {
       updateGameStateForFrame();
       sDisplay();  // DON'T call repaint()!
    }
  }

  public void paint(Graphics g) {
    sDisplay();
  }

    // REST OF Game Class (display()...) goes here
}

Stuart

Re: [gl4java-usergroup] Re: gl4java-usergroup digest, Vol 1 #105 - 4 msgs

[Artiste on t. W. <a1...@So...>]

Stuart Fischer wrote:
> > I have discover that the multi-threading can slow down the rendering !
> > Java may wait before really doing the rendering in the rendering thread,
> > and may coalesce rendering. Each frame in my game, i call a rendering,
> > but java coalesce them and i have only 1 real rendering for about 30-60
> > frames...
> Maybe I don't understand your problem, but I don't know if it is related to
> multithreading.
> 
> Are you calling repaint() once per frame in your game loop and calling
> sDisplay() in your paint() (or update()) method?
> 
> If so, Java WILL coalesce rendering.
> 
> If this describes your situation, call sDisplay() instead of repaint() in
> your game loop.

It is OK ! Thanks !

My FPS was about 7 and now it has risen to more than 100 !!!

> Simple example:
> 
> public class Game extends GLCanvas implements Runnable {
>   boolean gameOver = false;
> 
>   public void run() {
>     while(!gameOver) {
>        updateGameStateForFrame();
>        sDisplay();  // DON'T call repaint()!
>     }
>   }
> 
>   public void paint(Graphics g) {
>     sDisplay();
>   }

(I can't do this because paint is final in GLCanvas)

>     // REST OF Game Class (display()...) goes here
> }
> 
> Stuart

A11W

Re: [gl4java-usergroup] Re: PERFORMANCE

[Sven G. <sgo...@ja...>]

Artiste on the Web wrote:
> 
> Stuart Fischer wrote:
> > > I have discover that the multi-threading can slow down the rendering !
> > > Java may wait before really doing the rendering in the rendering thread,
> > > and may coalesce rendering. Each frame in my game, i call a rendering,
> > > but java coalesce them and i have only 1 real rendering for about 30-60
> > > frames...
> > Maybe I don't understand your problem, but I don't know if it is related to
> > multithreading.
> >
> > Are you calling repaint() once per frame in your game loop and calling
> > sDisplay() in your paint() (or update()) method?
> >
> > If so, Java WILL coalesce rendering.
> >
> > If this describes your situation, call sDisplay() instead of repaint() in
> > your game loop.
> 
> It is OK ! Thanks !
> 
> My FPS was about 7 and now it has risen to more than 100 !!!
> 

Well, you can check this bahavior in all the
GLAnimCanvas derived demos !

E.g.: The overworked gears demos in demos/MiscDemos of the upcoming 
GL4Java Release 2.4.1 (this night :-) I do upload it),
does have a command line attribute "-perftest" -> "java gears
-perftest",
where the setUseFpsSleep and setUseRepaint are called to set 'em to
false.

In this case, the AWT-renderer thread is NOT used for animation.
The reason for the slow down is the AWT renderer thread itself,
because if using repaint everything goes over this thread -> slow !

The sleep call, which is used to set the thread into a waiting state,
slows down the fps rate, because the threading block mechanism !

But be sure, the responsiveness of the application can be worse,
because the GL render thread may block other threads 
and can steal all the resources of the machine !
The minimal prerequisites are, that the JVM implements native threading
well
(the most uptodate JVM's) and that the OS supports mutli-threading well
- also 
(may be some problems with Win9X ?) !

I will notify ya all about the new version today !

Some more bugfixes I have todo ...

Yours, Sven

-- 
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442