Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (489)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (555)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why 4x better FPS when NetBeans is Running?  (Read 3055 times)
0 Members and 1 Guest are viewing this topic.
Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Posted 2004-03-14 23:27:54 »

I am running 1.4.2_01 on XP

When I start the game I am working on via webstart
http://freerails.sourceforge.net/jfreerails.jnlp
I get ~25FPS.

However, if I start NetBeans, then click on the webstart link I get ~100FPS.

If I then close NetBeans, and click on the webstart link, I get ~25FPS again.

Also, when I start two instances of the game, then minimize the one I started first, the second instance has ~100FPS while if I  minimize the second, the first instance still has ~25FPS.

Using 1.4.0_04 and 1.4.1_01 JREs, the problem does not occur, i.e. I always get ~100FPS

Any ideas?

Luke
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #1 - Posted 2004-03-15 00:37:14 »

See if you can profile it when it runs at ~25 and again when it is running at ~100.

And maybe file a bug report anyway... just in case.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-03-15 09:45:07 »

Quote
I am running 1.4.2_01 on XP


Try the latest JVM, not an old one. (1.4.2_04). Yes, it does have bugfixes in!

In general, if something works differently with 1.4.0_xxx then it's a bug in the older jvm. 1.4.0 was *very* buggy in some parts.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Reply #3 - Posted 2004-03-15 17:19:19 »

Profiling 1.4.2_01 while I wait for 1.4.2_04 to download...

The first instance started ~25FPS
1  
2  
3  
4  
Hotspots
35%      sun.java2d.pipe.SolidTextRenderer.drawGlyphList:38
33%      sun.awt.windows.Win32DDRenderer.clipAndDrawLine:76
6%      jfreerails.client.top.GameLoop.run:101


The second instance started while the first instance is running but minimised ~75FPS
1  
2  
3  
4  
5  
6  
Hotspots
17%      sun.java2d.pipe.SolidTextRenderer.drawGlyphList:38
15%      jfreerails.client.top.GameLoop.run:101
8%      sun.java2d.SunGraphics2D.clone:244
...
2%      sun.awt.windows.Win32DDRenderer.clipAndDrawLine:76


It is the same VM and executing the same line of code, so why is:

sun.java2d.pipe.SolidTextRenderer.drawGlyphList:38 7x faster

and

sun.awt.windows.Win32DDRenderer.clipAndDrawLine:76 48x faster?

Updated, the problem persists with 1.4.2_04.
Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Reply #4 - Posted 2004-03-15 18:16:03 »

Setting -Dsun.java2d.d3d=false made the problem go away and increased the frame rate to 110FPS.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2004-03-16 00:47:21 »

So, with the d3d=false it doesn't matter if you're running two applications or one, you always get 110 fps?

Have you tried 1.5 beta1?
Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Reply #6 - Posted 2004-03-16 07:34:27 »

Quote
So, with the d3d=false it doesn't matter if you're running two applications or one, you always get 110 fps?



From the command line, d3d=false always seems to work regardless of what else is running and gives me ~110FPS.  Setting ddoffscreen=false or noddraw=true
also works, but this only gives me ~80FPS.  Not setting any flags gives me ~25FPS.  

From webstart, setting d3d=false seems to have no effect, i.e. I get ~25FPS unless another java app is running.  Setting noddraw=true, however, does work and gives ~80FPS.

This is with 1.4.2_04.  I haven't tried 1.5 beta1 yet.
Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Reply #7 - Posted 2004-03-16 08:09:22 »

With 1.5 beta1

~95FPS with d3d=false
~70FPS with noddraw=true
~30FPS with no flags set
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2004-03-16 11:48:24 »

Quote
From webstart, setting d3d=false seems to have no effect


I suspect that the property gets set too late when set from Webstart.  AWT is already active and the decision to use d3d has already been made.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #9 - Posted 2004-03-17 01:14:18 »

Looks like some weirdness with the video drivers/DX/D3D.

What is your video board? What DX, driver version?

Try installing the latest driversif you haven't already.

Does your app set sun.java2d.translaccel property?

Also, could you please run your app from the command line with -Dsun.java2d.trace=count, let it run for a while, then quit and post the output.

Then, start some other java app (netbeans or whatever), and run your app with the tracing enabled.

I'm just trying to figure out if we're using different loops in the two cases.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 368
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-03-17 11:40:36 »

I'm no driver expert but I'm pretty sure that most D3D (and to a lesser extent, OpenGL) drivers are optimized for a single onscreen context, which is their expected usage as DirectX is designed to be a games API. The D3D APIs are not specifically bad at handling multiple contexts but the implementations are, as I say, tuned to deal with the common case one one context.

When you have two contexts the continual switching between one and the other is likely to cause severe performance degradation.

The decision to use DirectX in the rendering pipeline by default for Java2D was probably unwise. There are many instances of incompatibility, poor performance, or incorrect behaviour between multiple DirectX applications onscreen.

Cas Smiley

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2004-03-17 12:34:44 »

I agree that this is the most probable cause of this 'weirdness' - we've seen things like this before.

What would you suggest to use as an acceleration API on Windows?

Please don't say "OpenGL", it's drivers state is in much worse condition than DX.

GDI+? It's not accelerated, and will never be, according to some sources (and it'll basically die slowly and painfully anyway when Longhorn comes)

We did consider having a pure GDI pipeline, but, of course, not everything could accelerated.

Unfortunately, DX/D3D seems to be the only viable solution, even considering all its shortcomings.
Online princec

JGO Kernel


Medals: 368
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-03-17 13:29:39 »

Hm, I was under the impression GDI+ was a bit better at this sort of thing...

You're stuck with D3D if you don't want to use OpenGL at all (don't use DirectDraw!) - so it seems you need to find a way to get it to function a little more optimally. It should be possible to get it to cooperate a little better that it is though, I believe.

Out of interest, why don't you try using OpenGL drivers? You've got a reliable 65% of the Windows desktop then (I mean working OpenGL drivers, too). You've got all the code already in the Linux build. If you detect a decent OpenGL implementation you could use that as the primary path; then back off to Direct3D for the 35% that don't have GL drivers; then finally to GDI.

This ultimately would be of great benefit to you I think as your Mac and Linux codebases should be near identical. This will let you take care of the vast majority of desktop systems out there with one code path. (And remember we are talking very basic OpenGL functionality requirements here - no shaders or crazy stuff like that).

Need I also suggest that touting OpenGL as the primary accelerated API of choice on desktop systems will probably make the OEMs sit up and take a bit more notice of the proceedings.

Cas Smiley

Offline Mark Thornton

Senior Member





« Reply #13 - Posted 2004-03-17 13:51:38 »

Quote
Out of interest, why don't you try using OpenGL drivers? You've got a reliable 65% of the Windows desktop then (I mean working OpenGL drivers, too).

Isn't the problem deciding whether the OpenGL is reliable as opposed to just being present? Perhaps have a table of driver versions which are known to be adequate.
Online princec

JGO Kernel


Medals: 368
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2004-03-17 18:18:25 »

What a coincidence, I have such a table Smiley It's more or less the case that any GL driver advertising version 1.3 capability or above will be able to accelerate Java2D operations without problem.

Cas Smiley

Offline Luke

Senior Newbie




I love YaBB 1G - SP1!


« Reply #15 - Posted 2004-03-17 19:23:13 »

Quote
What is your video board? What DX, driver version?


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
------------------
System Information
------------------
Time of this report: 3/17/2004, 22:04:48
       Machine name: D1QDQL0J
   Operating System: Microsoft Windows XP Home Edition (5.1, Build 2600) Service Pack 1 (2600.xpsp2.030422-1633)
           Language: English (Regional Setting: English)
System Manufacturer: Dell Computer Corporation
       System Model: Dimension 2350
               BIOS: IntelR - 42302e31
          Processor: Intel(R) Pentium(R) 4 CPU 2.50GHz
             Memory: 254MB RAM
          Page File: 208MB used, 417MB available
Primary File System: n/a
    DirectX Version: DirectX 8.1 (4.08.01.0810)
DX Setup Parameters: Not found
     DxDiag Version: 5.01.2600.1106 32bit Unicode


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  
---------------
Display Devices
---------------
        Card name: Intel(R) 82845G/GL/GE/PE/GV Graphics Controller
     Manufacturer: Intel Corporation
        Chip type: Intel(R) 82845G Graphics Controller
         DAC type: Internal
        Device ID: Enum\PCI\VEN_8086&DEV_2562&SUBSYS_01471028&REV_03
   Display Memory: 64.0 MB
     Current Mode: 1024 x 768 (32 bit) (60Hz)
          Monitor: Dell E151FPp
  Monitor Max Res: 1024,768
      Driver Name: ialmrnt5.dll
   Driver Version: 6.14.10.3691 (English)
      DDI Version: 8 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 10/8/2003 10:12:28, 36927 bytes
    Driver Signed: Yes
  WHQL Date Stamp: n/a
              VDD:
         Mini VDD: ialmnt5.sys
    Mini VDD Date: 10/8/2003 10:11:20, 93979 bytes
Device Identifier: {D7B78E66-6622-11CF-F37D-4D21A2C2CB35}
        Vendor ID: 0x8086
        Device ID: 0x2562
        SubSys ID: 0x01471028
      Revision ID: 0x0003
         Registry: OK
     DDraw Status: Enabled
       D3D Status: Enabled
       AGP Status: Enabled
DDraw Test Result: All tests were successful.
 D3D7 Test Result: All tests were successful.
 D3D8 Test Result: All tests were successful.


Quote
Does your app set sun.java2d.translaccel property?

No

Quote
Also, could you please run your app from the command line with -Dsun.java2d.trace=count, let it run for a while, then quit and post the output.

Then, start some other java app (netbeans or whatever), and run your app with the tracing enabled.


Trace from first instance started, ~28FPS
Quote

38921 calls to sun.awt.windows.Win32BlitLoops::Blit("Integer RGB DirectDraw", SrcNoEa, "Integer RGB DirectDraw")
20637 calls to D3DDrawLine
470 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
48718 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(OpaqueColor, SrcNoEa, AnyInt)
1 call to sun.java2d.loops.Blit::Blit(ByteIndexed, SrcNoEa, IntArgbBm)
1 call to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgb)
21935 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb)
1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbBm)
1834 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
6 calls to GDIDrawRect
470 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArgb)
5 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "Integer RGB DirectDraw")
9677 calls to D3DDrawRect
21930 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "D3D texture destination")
1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgbBm)
2 calls to sun.awt.windows.Win32GdiBlitLoops::Blit(IntRgb, SrcNoEa, "GDI")
118 calls to GDIFillRect
470 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
151801 calls to DDFillRect
149 calls to GDIDrawLine
470 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArgb)
317617 total calls to 21 different primitives




And from the second instance, running while first instance is minimised ~95FPS
Quote

74420 calls to sun.awt.windows.Win32BlitLoops::Blit("Integer RGB DirectDraw", SrcNoEa, "Integer RGB DirectDraw")
470 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb)
4 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "Integer RGB DirectDraw")
43882 calls to D3DDrawLine
470 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb)
115148 calls to sun.java2d.loops.DrawGlyphList::DrawGlyphList(OpaqueColor, SrcNoEa, AnyInt)
1 call to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgb)
4930 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
4 calls to GDIDrawRect
1 call to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbBm)
31603 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb)
31599 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "D3D texture destination")
19794 calls to D3DDrawRect
470 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArgb)
2 calls to sun.awt.windows.Win32GdiBlitLoops::Blit(IntRgb, SrcNoEa, "GDI")
99 calls to GDIFillRect
1 call to sun.java2d.loops.Blit::Blit(ByteIndexed, SrcNoEa, IntArgbBm)
470 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArgb)
193677 calls to DDFillRect
1 call to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntArgbBm)
105 calls to GDIDrawLine
517151 total calls to 21 different primitives

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #16 - Posted 2004-03-18 01:41:53 »

Someone from Sun (Chet?) has already stated that a the OpenGL pipeline IS being maintained in the Windows code base.. and that perhaps some time in the future it could be included in the Windows JRE release.
I got the impression that it was simply the fact that there is no time to work out the kinks on Windows given that Windows already has acceleration through D3D and DirectDraw.

Too bad driver writers aren't more accountable for the problems they cause for everyone else.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #17 - Posted 2004-03-18 03:28:39 »

I'll leave it to Chris to ramble about the quality of OpenGL drivers on windows, especially on non-nvidia boards.

Unfortunately for us, not everybody has the latest Nvidia board with the latest drivers. In fact, the majority have some kind of on-board intel i8xx stuff, and opengl there doesn't fly (nor does d3d =).

Anyway, we too, think that we should have a complete D3D pipeline (no ddraw), because now we do too much switching between ddraw (blitting, locking), d3d (lines, rects, texture blits), which kills the performance.

Unfortunately, it won't happen in 1.5..
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #18 - Posted 2004-03-18 03:40:31 »

Luke, thanks for all the info.

It appears that in the second case we don't use d3d as much (I'm guessing because of some kind of drivers issue) for rendering rectangles/lines, and it works better as there is not as much context switching.

I'm not sure if we've tested on this particular board, I'll check tomorrow.

Unfortunately, I don't think the fix for this would be straightforward, and it's very doubtful it'll make it into 1.5.
The correct fix would likely involve rewriting our rendering pipeline on windows to use only D3D (or OGL)..
Pages: [1]
  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.

Nickropheliac (12 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

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

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

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

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

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

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

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

BurntPizza (47 views)
2014-08-09 21:09:32
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!