Potiential bug with full screen mode

[zparticle]

I am seeing a strange side effect of running in full screen mode in 1.4.0. Thought perhaps someone here could enlighten me as to the problem.

If I run my program several (10s of) times eventually the scolling goes from totally smooth to extreemly jerky and the frame rate drops dramatically. Sometime the program even starts to refuse to run telling me it "can't get the video mode".

If I change the resolution of the windows desktop to another resolution and then back to my normal resolution (not the res of the program) sometimes the problems goes away. Until another several runs. If I reboot the machine then the problems goes away, again until another several runs.

Is it possible that the image handling in Java 1.4 is somehow locking video memory and no releasing it? That is how the program reacts, as if it can no longer accelerate images due to incefficient VRAM.

[Abuse]

I am seeing a strange side effect of running in full screen mode in 1.4.0. Thought perhaps someone here could enlighten me as to the problem.

If I run my program several (10s of) times eventually the scolling goes from totally smooth to extreemly jerky and the frame rate drops dramatically. Sometime the program even starts to refuse to run telling me it "can't get the video mode".

If I change the resolution of the windows desktop to another resolution and then back to my normal resolution (not the res of the program) sometimes the problems goes away. Until another several runs. If I reboot the machine then the problems goes away, again until another several runs.

Is it possible that the image handling in Java 1.4 is somehow locking video memory and no releasing it? That is how the program reacts, as if it can no longer accelerate images due to incefficient VRAM.

I think it has already been established, that buffer strategy+fullscreen in jdk1.4.1_01 is broken in many places.

[zparticle]

Okay, but is this specific issue known to be a problem? I'm trying to determine if it is something I'm doing wrong or something I need to wait for a fix to resolve.

Games published by our own members! Check 'em out!

[zparticle]

Can't find anything specific to this in the bug database. However looking at the javadocs for BufferStrategy I'm wondering if perhaps I should be doing the following:

1   2   3   4   5   6   7

// when the program goes to exit BufferCapabilitites bc = myStrategy.getCapabilities(); // make sure the buffers are released if the strategy is a page flipping strategy if(bc.isPageFlipping())     ((Component.FlipBufferStrategy)myStrategy).destroyBuffers();

Any thoughts?

[Abuse]

if destruction of the buffers is not done automatically - then that is a bug in itself. However, I think it is. (as I have never come across this problem)

It sounds to me like a bug outside of Java. What gfx card are you using, whats the driver version, and what version of directX have you got installed?

[zparticle]

Video Card: GeForce4 Ti 4600
Drivers: The dlls all say version 6.13.10.3082 but the drivers tab says 3.0.8.2
OS: Win2k 5.0.2195 SP3
Direct X: not sure how to tell I think I have 8.something

[SpuTTer]

Try start->run->dxinfo

[Abuse]

Video Card: GeForce4 Ti 4600
Drivers: The dlls all say version 6.13.10.3082 but the drivers tab says 3.0.8.2
OS: Win2k 5.0.2195 SP3
Direct X: not sure how to tell I think I have 8.something

well, as far as im aware 3082 is the most uptodate available from nvidia. Spose it might be related specifically to the gf4, though I somehow doubt it.

You could also install dx9, though I very much doubt thats the cause of your problem.

Can you post the program that causes this problem, or is it repeated running of *any* java app that uses fullscreen exclusive?

[zparticle]

It appears to be any program that is: full screen and allocates a fair number of accelorated images.

I use 3 buffers in the strategy. Start from a fresh reboot and then run the program say 20 to 30 times. The scrolling demo I put up in the shared code area has this same issue. So I suppose I should try that on another machine and see if the problem occurs.

[Abuse]

scrolling demo? you got a link to that?

Games published by our own members! Check 'em out!

[zparticle]

http://www.java-gaming.org/cgi-bin/JGOForums/YaBB.cgi?board=share;action=display;num=1036252001;start=

[trembovetski]

I agree with Abuse, the DirectX should handle the cleaning up stuff for the application (j2se in this case). Unfortunately, in some cases it really doesn't (especially on Windows9x/ME). Haven't seen this on Win2K, though.

Try a test: make sure your app releases all (accelerated) images on exit (you can even release allocated vram yourself by calling flush() method on your Volatile and accelerated images), and see if it improves the situation.

[Abuse]

hey zparticle, I had some very disturbing problems last night  

though, this was while developing an app. that doesn't even use Fullscreen exclusive!

all this app. does, is call graphicsDevice.getDisplayModes()  

after about 30-40 runs (of the application, not the method), I got something like 'Internal Exception - unable to get DisplayModes'

then, Winamp (which was playing in the background) bombed out, java promptly crashed, and ate a sack full of resources (JCreator had insufficient resource to compile )

Last night I also noticed some weird goings on under the bonnet of java.

drawing an automatic image (with bitmask transparency) onto a fullscreen exclusive mode window running in 400x300x8.
By alt tabbing away, then alt tabbing back, I managed to get an 'Internal Exception - not implemented yet'!!

java.lang.InternalError: not implemented yet
     at sun.awt.windows.Win32OffScreenSurfaceData.getRaster(Win32OffScreenSurfaceData.java:278)
     at sun.java2d.loops.OpaqueCopyAnyToArgb.Blit(CustomComponent.java:67)
     at sun.java2d.loops.GraphicsPrimitive.convertFrom(GraphicsPrimitive.java:451)
     at sun.java2d.loops.MaskBlit$General.MaskBlit(MaskBlit.java:169)
     at sun.java2d.loops.Blit$GeneralMaskBlit.Blit(Blit.java:170)
     at sun.java2d.pipe.DrawImage.blitSurfaceData(DrawImage.java:658)
     at sun.java2d.pipe.DrawImage.renderSurfaceData(DrawImage.java:386)
     at sun.java2d.pipe.DrawImage.clipAndRenderSurfaceData(DrawImage.java:364)
     at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:66)
     at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:50)
     at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java:749)
     at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2803)
     at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:2793)
     at Particle.render(Particle.java:182)
     at ParticleAnim.render(ParticleAnim.java:115)
     at ParticleAnim.run(ParticleAnim.java:231)
     at java.lang.Thread.run(Thread.java:536)

Suffice to say, the FullScreen/BufferStrategy/VolatileImage are all quite severely broken.

just for a laugh, shall we create a new Thread, and post all the different low level exceptions that we can get FullScreen/BufferStrategy/VolatileImage to throw

I've already got a collection of 5 distinctly different 1s

[Silicon_Munky]

since FullScreen/BufferStrategy/VolatileImage is broken, what other safe way is there to get fullscreen with a backbuffer, all in VRam...?

[Abuse]

since FullScreen/BufferStrategy/VolatileImage is broken, what other safe way is there to get fullscreen with a backbuffer, all in VRam...?

use a different api.

LWJGL has support for fullscreen  

[Silicon_Munky]

anyone else know any other ways of doing this? other than LWJGL ??

[Silicon_Munky]

i thought driver 4.1.0.9 was the latest from NVidea

[Abuse]

i thought driver 4.1.0.9 was the latest from NVidea

I stand corrected,
though I still doubt that is the cause...
(but im downloading it as I type, just incase )