Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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
  ignore  |  Print  
  JOGLAppletLauncher and slow repaint on Firefox/Mozilla  (Read 8070 times)
0 Members and 1 Guest are viewing this topic.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Posted 2006-01-21 08:56:59 »

So from the early feedback from my game, it appears that the JOGLAppletLauncher runs at full speed on IE, and slooooow on firefox and mozilla.

I've done the following tests to identify the origin of the problem :
 - a simple awt canvas with buffer strategy swap ina loop runs in FF and > 3000 fps, so it's not a FF/Applet repaint problem
 - my ultra simple JOGLApplet (draws a single triangle) runs at 55 fps on my high end PC (independant of screen refresh rate : tried 60 to 75)
 
So there seems to be a problem with the JOGL repaint system (may be a contention/lock of the event dispatch thread ?)

I'm now going to try the direct approach (without the glenventlistener ) and see if it performs any better...

Lilian

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #1 - Posted 2006-01-21 10:05:30 »

Updated : tried direct approach (context.makeCurrent() / paint / context.release() and canvas.swapBuffers() in a loop) : 350 fps in a frame, 35 fps in FF, 350 fps in IE

any suggestions ?

Lilian

Offline thijs

Junior Member




Lava games rock!


« Reply #2 - Posted 2006-01-21 11:00:03 »

Strange,

Like I replied to your JackFlowers thread, I got ~350fps in FireFox, which was about the same for me in IE. (I used FireFox 1.5 and the 1.5.0_06 JVM)... So maybe the problem is FireFox 1.4 related?

<a href="http://www.dzzd.net">3DzzD!</a>
<a href="http://www.arcazoid.com">Arcazoid!</a>
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #3 - Posted 2006-01-21 15:07:34 »

No, I've switched from FF 1.0.7 to 1.5 and the problem remains on my desktop PC (on the laptop, it's still a good 200 fps)

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #4 - Posted 2006-01-21 21:07:41 »

Actually I can reproduce this problem. I see 150 FPS in IE and only 20 FPS in Mozilla 1.7.6. This is with J2SE 1.5.0_06 on Windows XP SP1 with NVidia graphics hardware.

My best guess at this point would be architectural differences between the Java Plug-Ins for IE and Mozilla. I don't know a lot about how the Plug-In works but know that there are effectively two different code bases due to how the different browsers work. I thought that at one time the Mozilla plug-in actually ran out-of-process or something similar. Maybe that's changed. I do think it is strange that a pure Java2D applet could get extremely high frame rates while JOGL applets would be slow. I don't think JOGL's locking or repainting code would be the problem especially if the same code runs fine in IE but anything's possible.

I'll ask some people more familiar with the Plug-In to take a look at this next week. In the meantime if you have a chance to do any instrumentation of the JOGLAppletLauncher to see where all of the time is going (makeCurrent()? swapBuffers()? release()?) that would be helpful.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #5 - Posted 2006-01-22 15:13:20 »

Actually I can reproduce this problem. I see 150 FPS in IE and only 20 FPS in Mozilla 1.7.6. This is with J2SE 1.5.0_06 on Windows XP SP1 with NVidia graphics hardware.

My best guess at this point would be architectural differences between the Java Plug-Ins for IE and Mozilla. I don't know a lot about how the Plug-In works but know that there are effectively two different code bases due to how the different browsers work. I thought that at one time the Mozilla plug-in actually ran out-of-process or something similar. Maybe that's changed. I do think it is strange that a pure Java2D applet could get extremely high frame rates while JOGL applets would be slow. I don't think JOGL's locking or repainting code would be the problem especially if the same code runs fine in IE but anything's possible.

I'll ask some people more familiar with the Plug-In to take a look at this next week. In the meantime if you have a chance to do any instrumentation of the JOGLAppletLauncher to see where all of the time is going (makeCurrent()? swapBuffers()? release()?) that would be helpful.


here's a basic applet loop (don't know if the code is correct, but it works fine (except fps) on both IE & FF (>1000 fps IE, 30 fps FF)

(The loop is started as a thread with default priority)

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  
  double start = System.nanoTime() * 1E-6;
  void profile(String text){
    double now = System.nanoTime() * 1E-6;
    System.out.println(text + " : " + (now - start) + " ms");
    start = now;
  }
 
  public void run(){
    System.out.println("making current");
    GLContext context = canvas.getContext();
    context.setSynchronized(false);
    System.out.println("autoswap off");
    canvas.setAutoSwapBufferMode(false);
     
    GLU glu = new GLU();
   
    profile("before loop");
    while ( ! destroyed){      
      profile("before makeCurrent");
      context.makeCurrent();
      profile("after makeCurrent");
      //System.out.println("get gl");
     GL gl = context.getGL();
      gl.setSwapInterval(0);
      int height = getHeight();
      int width = getWidth();
      if (height <= 0){ // avoid a divide by zero error!
       height = 1;
      }
     
      final float h = (float) width / (float) height;
      gl.glViewport(0, 0, width, height);
      gl.glMatrixMode(GL.GL_PROJECTION);
      gl.glLoadIdentity();
      glu.gluPerspective(45.0f, h, 1.0, 20.0);
      gl.glMatrixMode(GL.GL_MODELVIEW);
      gl.glLoadIdentity();
     
     
      gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
      gl.glLoadIdentity(); // Reset The View
     gl.glTranslatef(0.0f, 0.0f, -5.0f);
      gl.glColor3f(1,1,0);
      gl.glBegin(GL.GL_TRIANGLES);
      gl.glVertex3f(1,0,0);
      gl.glVertex3f(1,1,0);
      gl.glVertex3f(0,1,0);
      gl.glEnd();
     
      profile("before flush");

     
      //System.out.println("flush !");
     gl.glFlush();
      //System.out.println("swapping");
     profile("before release");
      context.release();
      profile("before swap buffers");

      canvas.swapBuffers();
      profile("after swap");

    }
   
  }


This code shows problems with
- makeCurrent ( > 15millis on FF, never above 1ms in IE)
- swapBuffers ( > 15 millis on FF, < 3 mills in IE)

flush, release and internal gl calls are all sub-millis


Lilian





Offline Ken Russell

JGO Coder




Java games rock!


« Reply #6 - Posted 2006-01-22 18:25:31 »

Try moving the swapBuffers() call before release(). That should eliminate the time for swapBuffers since it avoids making the context current again. This is how the JOGL internals are structured.

There are only two operations that could be taking the time here: locking the surface wtih the JAWT and actually doing the wglMakeCurrent call. My guess would be that somehow locking the surface is taking more time in the plug-in, though I can't guess why.

Could you also print out whenever GLContext.makeCurrent() returns CONTEXT_CURRENT_NEW? That should happen exactly once but I'd like to ensure it isn't happening every frame.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #7 - Posted 2006-01-22 18:53:19 »

Ok i'll try it tomorrow (but the problem will remain as the game applet, which is based on GLEventListener also shows poor performance... )

From what you say I guess the makeCurrent() call is the problematic one, and the release/swapBuffers is just a bug for this specific applet.

Lilian

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #8 - Posted 2006-01-23 09:18:46 »

Tried moving swapBuffers before release()... this caused either a hang or an exception depending on context.setSynchronized(true/false)

The stack trace shows that the swapBuffer invokes maybedosinglethreadworkaround which sends the request swap to another thread.

I've also tried with -Dopengl.1thread=false, it solved the exception, but the delay was worse for swapBuffers (around 30 ms).

And last test : the makeCurrent() returns CONTEXT_CURRENT_NEW only once at the beginning.

Oh, and I've also checked the EventQueue.invokeAndWait(Runnable) with a dummy runnable (not GL related), and I can perform 100 calls in 6 ms, so this is not the origin of the problem.

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #9 - Posted 2006-01-24 08:45:38 »

Tried moving swapBuffers before release()... this caused either a hang or an exception depending on context.setSynchronized(true/false)

The stack trace shows that the swapBuffer invokes maybedosinglethreadworkaround which sends the request swap to another thread.

Sorry about that. I should have realized that would happen. That might be considered a bug. However I'm leery of adding too much mechanism in this area.

Quote
I've also tried with -Dopengl.1thread=false, it solved the exception, but the delay was worse for swapBuffers (around 30 ms).

That -D or calling Threading.disableSingleThreading() would be the only way to work around the issue. I'm very surprised that swapBuffers would be taking this long.

Quote
And last test : the makeCurrent() returns CONTEXT_CURRENT_NEW only once at the beginning.

Thanks for verifying that.

Quote
Oh, and I've also checked the EventQueue.invokeAndWait(Runnable) with a dummy runnable (not GL related), and I can perform 100 calls in 6 ms, so this is not the origin of the problem.

Thanks for checking this as well.

I think more instrumentation is needed in the WindowsGLContext and WindowsOnscreenGLContext implementations to see exactly where all of the time is going. I'll try to get to this within the next couple of days and get some people more familiar with the internals of the Java Plug-In to look at a test case. BTW, do you have a particular small applet which exhibits the problem? Is it reproducible with the standard Gears applet if the call to GL.setSwapInterval(1) is removed?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #10 - Posted 2006-01-24 09:01:02 »

Here's a full small problematic applet

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #11 - Posted 2006-01-29 05:14:36 »

Thanks for the test case. I wrote another one based on it (attached) using just the normal GLEventListener mechanism and put some profiling stuff deeper into JOGL. It looks like all of the time is going in to the low-level call to the WINGDI routine SwapBuffers(). I have no idea why this would have different behavior from one Java Plug-In environment to another. It's very obvious that when run inside the appletviewer or IE's plug-in SwapBuffers takes basically zero time, but when in the Mozilla/Firefox plug-in it's taking on the order of 9 ms/frame. WGL_EXT_swap_control is reported as available in all situations, the chosen pixel format is exactly the same, etc. The thing that's most confusing to me is that SwapBuffers is a very low-level call which doesn't even generate a Windows event, and since the plug-in is essentially just a wrapper around a normal JVM, how could any differences in the Windows event dispatching between the two plug-ins make any difference? Anyway, now that I have an instrumented test case I'll contact the plug-in team next week and try to figure out what's going on.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #12 - Posted 2006-02-03 17:49:51 »

Hi, is there an issue # to track this problem ? should I file one ?

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2006-02-03 18:25:51 »

Yes, please feel free to file one.

We have done some further investigation of this problem internally and it's pretty mystifying. My co-worker's two machines with NVidia cards (one with older drivers, one with current drivers) do not exhibit the problem. My old office machine with a GeForce FX 5800 Ultra did, so it's not something like running low on VRAM (which might be the case on the notebook where the problem also occurs). We eliminated things like the Firefox version as variables. I've been in discussions with co-workers who work on the Java Plug-In and we can't think of a way that the event dispatch structure of the plug-in can affect the speed in this way. I'm thinking it might be something about how Mozilla sets up the window it hands to Java; I checked though and one thing is that Mozilla doesn't load DDRAW.DLL, which is the only thing I know of that could cause a driver-level incompatibility with OpenGL resulting in a symptom like this. We're continuing to look into it and I may post on NVidia's web site for some help once we've characterized it a little better.

Could you please tell us exactly what CPU types and speeds, OS versions, graphics cards and driver versions the slowdown happens with? Maybe we can identify a pattern.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #14 - Posted 2006-02-03 18:36:14 »

Could you please tell us exactly what CPU types and speeds, OS versions, graphics cards and driver versions the slowdown happens with? Maybe we can identify a pattern.

Actually I just went back and reread the Jack Flowers thread so see that it's happening with both ATI and NVidia hardware.

Looks like we might need to support a way to specify -Dsun.java2d.noddraw=true for applets as well as Java Web Start applications. Unfortunately due to the applet lifecycle model (in the browser) I'm not sure that's possible.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #15 - Posted 2006-02-04 09:35:05 »

Just to add something : the -Dsun.java2d.noddraw=true resolves ATI freeze issues (long pauses every n seconds), not the slow frame rate.

I've just checked this on my desktop pc (nvidia) : still around 30 fps with noddraw on FF (300 fps with IE)

Lilian

Offline sambro

Senior Newbie





« Reply #16 - Posted 2006-02-04 09:46:08 »

Hi guys,

I'm not sure if this is related, but I'm having problems getting any higher than 60fps in any JOGL applet, FF, IE, Applet Launcher or otherwise. I also do not think it is related to JOGLAppletLauncher either, as I used my own applet launcher, and also tried just using JOGL directly in a Frame.

I used the JGears applet as another test, to make sure it wasn't my code. Even using the FPSAnimator, I couldn't get higher than 60fps, another strange symptom is if I try and tell it to run at, for example, 40fps, my FPS come out at around 33.

I'm using jdk1.5.0_06, the poor performance is not related to my PC either: 3.2ghz, 1.5gb ram, 256mb GeForce 6800.....

Drop me a line at me@sambro.info if you want me to run any tests/debug.

-Sam

EDIT:
Vendor: NVIDIA Corporation
Renderer: GeForce 6800 GT/AGP/SSE2/3DNOW!
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #17 - Posted 2006-02-04 09:58:53 »

Well I guess your rendering is in sync with your monitor's frame rate. Did you try to unlock vsync from your graphics card control panel ?

Also does this game shows the same behaviour (http://www.javapause.com/games/jack) ? it uses an opengl call to disable vsync.

Lilian

Offline sambro

Senior Newbie





« Reply #18 - Posted 2006-02-04 10:12:23 »

Ahhh I feel stupid Angry Thanks Lilian Smiley
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #19 - Posted 2006-02-04 16:31:08 »

After more investigation it currently looks to me like the slower performance in Mozilla/Firefox looks a lot like wglSwapIntervalEXT(0) silently failing. I've posted on opengl.org describing some of the tests that have been done and asking for any input. Let's see if there are any responses.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #20 - Posted 2006-02-09 08:12:15 »

I've also filed a bug in the bugzilla system of Mozilla/Firefox just in case... with a link to your post on opengl.org

I've also tried the game with FF on mac os : runs fine at full speed.

What's strange is that it works fine on my laptop, with FF 1.5.1, and an nvidia 6200 (I've tweaked the nvidia options, especially the once related to vsync but couldn't reproduce the bug on this computer).

I'm thinking of a kind of back buffer used by ff to avoid direct painting of applets into their tabbed windows (I've seen some old bugs saying applets were painted in the wrong tabs). In that case, the opengl rendering would have to be send to this buffer, then by FF to the screen. As I don't know anything of FF internals, I might be absolutely wrong. And that doesn't explain why it works on my laptop, and not on my desktop PC (NV6600).

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #21 - Posted 2006-02-09 09:04:51 »

I'm thinking of a kind of back buffer used by ff to avoid direct painting of applets into their tabbed windows (I've seen some old bugs saying applets were painted in the wrong tabs). In that case, the opengl rendering would have to be send to this buffer, then by FF to the screen. As I don't know anything of FF internals, I might be absolutely wrong. And that doesn't explain why it works on my laptop, and not on my desktop PC (NV6600).

I downloaded the FireFox sources a few days ago and looked through the Windows graphics implementation a little. However I didn't see anything obvious in how it sets up its WNDCLASS or its HWND instances themselves that looked "strange" and that might somehow interfere with OpenGL. There is no way that a GDI-based back buffering scheme for Firefox could possibly interfere with the implementation of SwapBuffers as far as I know. I'll wait a couple more days to see if there are any replies on opengl.org and will then probably post the same question on NVidia's forums.

FYI, a co-worker has been looking at the Jack Flowers applet and seen quite a bit of instability (JVM crashes) even on NVidia hardware. I think he's going to try putting -Dsun.java2d.noddraw=true in his control panel settings and test it again, but the fact that those kind of problems are showing up make me reluctant to recommend using applets as a deployment technique for JOGL apps. Let's see how further testing looks.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #22 - Posted 2006-02-09 10:06:49 »

I've also found on the web a workaround to force setting a property to the applets without going through the plugin control panel... I'll explore this path in the coming days to install -Dsun.java2d.noddraw=true (with the consent of the user, not silently).


Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #23 - Posted 2006-02-09 23:24:04 »

I've also found on the web a workaround to force setting a property to the applets without going through the plugin control panel... I'll explore this path in the coming days to install -Dsun.java2d.noddraw=true (with the consent of the user, not silently).

How does this work? I would be very surprised if it were possible to do this in any way that actually had an effect. This property only has an effect if it is specified before any windows are created, so if for example it's set in the JOGLAppletLauncher it's already too late.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #24 - Posted 2006-02-18 17:15:52 »

here's the workaround : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6260751

What we have to do is to check if the opengl driver is an ATI
  if true, check if sun.java2d.noddraw is set to true
    if false show a dialog to the user requesting his approval to install the workaround (in a user friendly way : "your 3D card may have problems with java and opengl technology, do you accept this program to install a patch to overcome these issues ?, this patch will also affect other java applets" or something better).
    if the user accepts, add the property to the deployment file, and ask the user to restart his browser

This sequence must be done from the signed applet otherwise we'll encounter security issues.

Ken, what's your opinion on this ?

Lilian

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #25 - Posted 2006-02-18 23:18:58 »

That sounds like a good workaround to me. Would you mind coding it up or should I? If you don't have time, please file a bug with the JOGL Issue Tracker.
Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #26 - Posted 2006-02-19 09:17:32 »

I'll do it in a couple of days (let's hope nobody will complain about it : the workaround is for every applet, not just ours)

Lilian

Offline cylab

JGO Ninja


Medals: 38



« Reply #27 - Posted 2006-02-19 13:47:58 »

Hmm, wouldn't this break hardware accelleration for Java2D game applets?

Mathias - I Know What [you] Did Last Summer!
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #28 - Posted 2006-02-19 15:30:24 »

After more investigation it currently looks to me like the slower performance in Mozilla/Firefox looks a lot like wglSwapIntervalEXT(0) silently failing.[...]

That swapinterval bit is more like a hint. You can also call it without a param to get the currently used value... well, thats how its supposed to work, but currently only Nvidia actually supports that (havent tested it for more than a year tho... eventually it works now with ATI, too)

On the driver side you usually have 4 possible settings for vsync. Always on, on by default, off by default and always off. Only if its #2 or #3 you can change it from your application.

弾幕 ☆ @mahonnaiseblog
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #29 - Posted 2006-02-19 22:31:25 »

Hmm, wouldn't this break hardware accelleration for Java2D game applets?

You're right, it would. The question is whether that would perceptibly slow things down. I have found that the WIndows GDI pipeline for Java2D is just as fast as the DirectDraw pipeline for most operations and applets I've seen. Try setting -Dsun.java2d.noddraw=true in your Java Control Panel and please post if you see significant slowdowns for applets you commonly run (and please post the locations of those applets as well).
Pages: [1] 2
  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.

pw (11 views)
2014-07-24 01:59:36

Riven (10 views)
2014-07-23 21:16:32

Riven (11 views)
2014-07-23 21:07:15

Riven (12 views)
2014-07-23 20:56:16

ctomni231 (42 views)
2014-07-18 06:55:21

Zero Volt (38 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (34 views)
2014-07-16 23:30:00

Cero (50 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!