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 (532)
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  
  Windows tooltips/menus hammer 2D drawing  (Read 2134 times)
0 Members and 1 Guest are viewing this topic.
Offline immudium

Junior Member




Gorram it!


« Posted 2003-11-06 16:32:00 »

This may have been asked before, but for the life of me I can't find a fix or workaround.  I have an app in Windowed mode, using ManagedImages for sprites that are animated with a Canvas using a BufferStrategy of 3.  It hums along just lovely at about 300 fps until the off chance that the mouse "lingers" over an icon or anything that has a tooltip.  Once that tooltip pops up frame rate goes to hell even if my main java window still has the focus.  Once the tooltip's time is up and goes away everything returns to normal.  Menus hurt performance quite a bit as well outside of the app, but java menus within the program don't.  I'm not too concerned with the menus hammering drawing, but the tooltips are everywhere, the system clock, the taskbar, etc.

I've tried adding sun.java2d.ddforcevram=true and sun.java2d.translaccel=true as well as any other obscure 2D argument I can find to my VM arguments and none seem to make any difference at all.

I am using WindowsXP and JDK 1.4.2_02-b03.  The video card is an NVidia 5200 using the latest 52.16 drivers.  I can post any of my souce code if you think it might help, but I am just using a pretty general, frame-limiting animation loop using the Perf timer that has been discussed pretty extensively here in the Java2D forum.  Images are created using gConfig.createCompatibleImage(width, height, Transparency.OPAQUE)  Is this a pretty common problem, or am I missing something obvious or doing something wrong?

Thanks for any ideas.   Smiley
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #1 - Posted 2003-11-07 13:30:35 »

Try forcing tooltips and popup menus to use heavy weights (see the Javadocs).  I'm guessing it is some interaction with the tooltip painting that is causing Java2D to "un-manage" some image.  Maybe the nature of the drawing calls to do the tooltip cause the underlying surface to be shunted back to normal RAM? Just guessing.

Offline immudium

Junior Member




Gorram it!


« Reply #2 - Posted 2003-11-07 15:22:19 »

Hi swpalmer,
I initially thought it could be a conflict with heavyweights and lightweights in java, but the real blow to performance are really all the external windows tooltips and menus that I have no control over from within Java.  And the real kicker is when I add the flag "sun.java2d.noddraw=true".  Theoretically I should lose all hardware acceleration when that flag is enabled, but when I do so, there is no performance hit whatsoever from any external Windows XP controlled menu, tooltip or drawing.  And what's even better is that even though my total frames are less when that flag is enabled, my overall performance is more stable with sun.java2d.noddraw=true overall.

For some tangible numbers, with the default setting sun.java2d.noddraw=false my total fps will drop from over 300 fps to under 100 fps by just hovering my mouse over the system clock and allowing the tooltip to show.

With sun.java2d.noddraw=true, my total frames are at 150 fps and stay at 150 fps no matter what external windows tooltips or menus are being shown.  

It would seem, then, that there is something terribly wrong with DirectDraw in Java2D in windowed mode.  Perhaps directdraw cannot coexist peacfully with GDI?  But if that's the case, it seems to me sun.java2d.gdiblit=false would help matters when directdraw is enabled but it doesn't help anything.

Anyway, I'm going to try to run Borland's Optimizeit and see if I can spot anything.  Any ideas on what I should be looking for?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline immudium

Junior Member




Gorram it!


« Reply #3 - Posted 2003-11-07 16:50:21 »

OK, here's the stack traces from OptimizeIt.  The first one shows me leaving the mouse in one spot so that it doesn't accidentally hit anything that might render a tooltip.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
1.17% - 516 ms - java.awt.Component$BltBufferStrategy.show()
            0.16% - 72 ms - sun.java2d.SunGraphics2D.drawImage()
               0.16% - 72 ms - sun.java2d.SunGraphics2D.drawImage()
                  0.16% - 72 ms - sun.java2d.pipe.ValidatePipe.copyImage()
                     0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                        0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                           0.16% - 72 ms - sun.java2d.pipe.DrawImage.copyImage()
                              0.16% - 72 ms - sun.java2d.pipe.DrawImage.renderSurfaceData()
                                 0.16% - 72 ms - sun.java2d.pipe.DrawImage.blitSurfaceData()
                                    0.01% - 5 ms - sun.java2d.loops.Blit.getFromCache()
                                       0.01% - 5 ms - sun.java2d.loops.RenderCache.get()


In this second one I am simply hovering my mouse over the various icons in my taskbar.

1  
2  
3  
4  
5  
6  
7  
8  
9  
82.91% - 34324 ms - java.awt.Component$BltBufferStrategy.show()
            82.63% - 34207 ms - sun.java2d.SunGraphics2D.drawImage()
               82.63% - 34207 ms - sun.java2d.SunGraphics2D.drawImage()
                  82.63% - 34207 ms - sun.java2d.pipe.ValidatePipe.copyImage()
                     82.63% - 34207 ms - sun.java2d.pipe.DrawImage.copyImage()
                        82.63% - 34207 ms - sun.java2d.pipe.DrawImage.copyImage()
                           82.62% - 34202 ms - sun.java2d.pipe.DrawImage.copyImage()
                              82.62% - 34202 ms - sun.java2d.pipe.DrawImage.renderSurfaceData()
                                 82.62% - 34202 ms - sun.java2d.pipe.DrawImage.blitSurfaceData()


There is more to the stack trace that I can show, but these seemed to be the most different in execution time.  Is there anything to explain this?
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2003-11-07 17:33:42 »

Hmm... sounds like it is having problems getting a drawing context or something.

Where's Trembovetski or Chet or one of those guys?  They would likely be able to give the right answer.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2003-11-11 02:31:11 »

Well, I'm back from Hawaii =)

I think this could be some kind of conflict between Java2D and the OS using Direct3D at the same time, causing context switching and all kinds of other bad stuff.

BTW, your monitor refresh rate isn't set by any chance to 100hz?
Offline immudium

Junior Member




Gorram it!


« Reply #6 - Posted 2003-11-11 05:15:40 »

Welcome back!  I hope the fresh air and sunshine did you some good.

Anyway, my monitors refresh rate is set at 85Hz.  However, since I last posted I've had the chance to run my code on two additional test machines, both of which are similarly configured to my own (WinXP, DirectX 9, 512+ MB memory, NVidia video cards with identical video drivers and greater than 2GHz CPUs) and although both take a hit when tooltips show, neither seems to suffer nearly as much as my development system.  That said, the only real hardware difference my machine has that the other two do not is the use of Rambus system memory.  Perhaps it has a hard time simply due to the high latency nature of Rambus and perhaps not.  I wish I could test on another Rambus based system, but they have always been a little scarce and remain so especially now.  However, even with this blatant, non-scientific shot in the dark, setting -Dsun.java2d.noddraw=true absolutely fixes any hits to my framerate resulting from Windows tooltips, so the problem is definitely in DirectDraw somewhere.  Doesn't make any sense to me.  Perhaps it's nothing more than "Wall of Weird" material. [EDIT] I.e. if you're not familiar with Smallville, not something to forget about, but rather something you set to the side and look at every once in a while and say "Huh, that's kinda weird"  And then go back to your normal Java2D blissful routine until one day it decides to attack while you're taking a swim by yourself in the high school gym in the middle of the night. [/EDIT]
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #7 - Posted 2003-11-11 08:42:31 »

wow!

I just tested the game im writing atm, and tooltips do indeed kill performance Shocked

Mine drops from a constant 60, down to 45 :-/

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #8 - Posted 2003-11-11 09:02:26 »

hmm, I just tested Q3 and UT.

Q3 uses ogl, and showed no degradation in framerate when the tooltip was active. (between 170 and 180fps)

UT was using D3D, and showed a significant (though not massive) degradation in framerate. (went from 8ms to render a frame, to 10ms)

Weird Kiss

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline chet

Senior Newbie




Java games rock!


« Reply #9 - Posted 2003-11-11 19:28:25 »

interesting phenomena; I hadn't noticed this one before.

From the various descriptions of the problem (including all the flags you tried), it sounds like it's some horrible (and unavoidable?) context-switching bottleneck.  In particular, a tooltip or menu (especially with the translucent menu fade effect of win2k/XP) would be doing heavy GDI rendering.  Meanwhile, Java2D is doing heavy DirectX rendering.  Sometimes, depending on the hardware and driver, the context switch between these libraries can be quite horrible;
a real performance killer.  We have run into similar situations inside of Java2D that we tried to fix (for example, when we used to use ddraw for hor/vert lines and GDI for diagonals it caused serious performance problems just due to the ctxt switching; we now use d3d when we can which seems to help that specific problem immensely).

By using translaccel and ddforcevram, you are telling us that yes, you really want to use DirectX for these operations.  So the images/buffers stay cached in VRAM and we use the ddraw Blt engine or d3d texture engine to copy stuff around in hw.  By using noddraw, you are ensuring that we do not such thing; all images/buffers live in the Java heap and we copy the bits down to the screen over the bus using GDI.  The fact that there is no fps change when noddraw is present implies that our GDI copy coexists happily with the desktop GDI operations (another pointer toward painful context switching).  The fact that you are seeing different behavior on different systems in another indicator that the problem is card/driver-based; perhaps the card on your original system just has a driver that's horribly inefficient at context switching.

Unfortunately, I don't have a fix for you.  Our use of directX allows us to get the great frame rates you are getting by default (300 fps).  But that approach apparently conflicts with basic desktop functionality because of GDI/DX coexistence problems on that configuration (my theory, boldly stated but completely unproven...).  so I think you've already seen your choices clearly; either choose the higher frame rate which can unfortunately hiccup given other occurrences outside the app, or choose the lower non-hw-accelerated framerate that is apparently more desktop-compatible.  Or got into fullscreen mode and avoid the issue.

Some things that occur to me that you can try (more for data-gathering purposes that any real workarounds...):
- Try to force us to use ddraw locking to copy to the screen when ddraw is disabled.  I would expect similar crummy results because we're still forcing context-switching to occur (without the benefit of the higher frame rate of hw acceleration).  To do this, use the flags:
   -Dsun.java2d.ddoffscreen=false
   -Dsun.java2d.gdiblit=false
   -Dsun.java2d.ddlock=true
This combo tells us: don't use ddraw for offscreen surface caching (but still use it for other operations), don't use GDI to copy bits down to the framebuffer, do use ddraw to copy bits to the screen.  note that this does not enable translaccel, so your alpha images will be in system memory.
I'm thinking that your framerate would be about equal to (or possibly a little better than) your 150 fps number with noddraw set, but that it would suffer during the tooltip/menu situations.

- Try changing your desktop effects to avoid translucency fades, or anything that smacks of GDI animation.  This could avoid too much GDI/DX thrashing during these operations.

Good luck....

Chet.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline immudium

Junior Member




Gorram it!


« Reply #10 - Posted 2003-11-12 14:30:40 »

Wow, thanks.  The information and ideas are very much appreciated and more than I could have hoped for.

Anyway, part of the initial angst over this occurred when I suddenly realized that my new, cool, clever animation loop was neither cool nor as clever as I had hoped.  It suffered considerably with this particular fluctuation of framerate.  Thus, I was forced to take a hard look at it again and as a result, I'm happy to report my overall animation code seems to be much more solid now.  I was able to incorporate some of Marcus_Persson's excellent interpolation ideas from his descrete step timing loop thread as well as a few techniques from Jeff's scroller example for controlling framerates.

Anyway, I have also been trying a few of the additional switches you suggested and so far results seem to be as you predicted.  I didn't notice any difference with -Dsun.java2d.noddraw=true coupled with:
-Dsun.java2d.ddoffscreen=false
-Dsun.java2d.gdiblit=false
-Dsun.java2d.ddlock=true

However, one interesting phonomena I noticed; if I remove the noddraw flag above, but leave the others there, all tooltips external to Java flicker wildly including those in the Windows toolbar.  Tooltips internal to Java seem unaffected, though, and my framerate remains the same as noddraw=true in this case.

In any event, I've added a little dialog that will allow the user to turn off DirectDraw at the expense of some eye candy, if it is an issue for them and they are unwilling to tweak the fade effects in Windows which does seem to make a big difference.  And with the excellent explanation and UT benchmarks (Thanks Abuse, it never occurred to me to try another DirectX application such as Unreal Tournament) I have some ammunition in the event that anyone actually notices the performance hit and calls me on it. Cool

Many thanks to all.

-Immudium
Offline chet

Senior Newbie




Java games rock!


« Reply #11 - Posted 2003-11-12 16:15:04 »

Immudium,

Glad you found some workarounds.  Note that the flag combo I specified above was intended to be tried _without_ the noddraw flag (which I see you tried as well); when you specify ddraw, we don't do anything at all through directX.  But with the flag combo listed (not including noddraw), we will use ddraw for locking the screen and copying the bits.

The lovely flickering you noticed in your test of these flags is exactly why we started using GDI to copy bits to the screen instead of ddraw; when we lock the screen and copy the pixels, GDI animation loops completely halt and those objects do not get painted to the screen during that lock/unlock period.  This includes the fading menus as well as software cursors (on platforms without hw cursor support, such as most Matrox cards).

Anyway, glad to hear you've found some things to alleviate the situation.  Good luck...
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.

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

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

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

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

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

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

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

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

Cero (51 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!