This is how DirectDraw applications (which java 6u6 is) behave
while in full screen mode. We don't have any control over this
(that I'm aware of) - when full screen application loses focus,
DirectDraw minimizes it.
As for the exception - you're creating the buffer strategy on one
thread while the display change event (or some other event
which invalidates the BS) happens on another
(EventDispatchThread). This event invalidates the buffer strategy
and there's a race condition between the two threads.
It's a bug (hard to fix, unfortunately) - I think there's a bug
filed somewhere.
There are some workarounds for this kind of errors, like
suspending your rendering loop while the window is iconified,
executing your display enter/exit and display change modes on
the EDT, as well as buffer strategy creation. But the race
will still be there, you may just reduce the probability..
Also, I would suggest to test your application on 6u10 since
full screen mode has been reworked there (along with the default
Java2D rendering pipeline). I'm not saying it's
any better, but it may behave differently.
Thanks,
Dmitri
[EMAIL PROTECTED] wrote:
[ This is windows, java 1.6.0_06-b02.]
I have two monitors.
I'd love to have Full Screen Exclusive (FSE) running on one of them,
controlling its contents from another. Think slideshow on projector while
presenter have his script on the monitor (where the slideshow in question have
lots of animation (!), thus non-tearing flip BufferStrategies would be nice).
I however get a problem, which I guess is related to when FSE is used on single-monitor
setups: the FSE stuff minimizes right away when another application gets focus, which
happens both on alt-tabbing, and when I run the mouse out of the FSE onto the other
monitor and click on some app (actually, for my part, having "point to focus",
it happens when I point onto another applications window for some hundred millis).
I get why it has to be like this for single-monitor boxen (how else should you get back
to the OS, so to speak), but it severely limits the usefulness of FSE on multi-monitor
setups. It is quite apparent that this is "coded with intention", and that what
I request would be possible, because as long as I don't give away focus, I can roam
around on the other desktop (the non-FSE) as much as I want, all applications still
running, and the FSE is fully working with flip BufferStrategy and no tearing - so it
really seems perfect.
There seems to be a "workarond" in that the loosing of focus seems to be confined to the
application, not to the FSE "window" or other windows of that application. This means that I can
have FSE in one monitor for the slideshow (in the above application scenario), while having a *Maximized*
application window on the other monitor. But this isn't really workable either, as merely getting focus on
the Windows Taskbar "kills" the FSE.
I tried installing a WindowListener, and on windowInconified (which seems to be the event
that just appears out of nowhere), I do a frame.setExtendedState(0). But this is rather
hacky, and doesn't quite work - it blinks and flashes and in particular, I seem to loose
the V-synching ("tear-free") and the speed slows significantly for some reason.
(This also sometimes happen on normal restore, however. One hunch is that this
auto-re-maximizing goes too fast: the VRAM hasn't been released before it has to
re-acquire buffers).
During my testing (with the same application running all the time), I also
ended up with this exception:
Exception in thread "Thread-2" java.lang.IllegalStateException: Buffers have
not been created
at sun.awt.windows.WComponentPeer.getBackBuffer(WComponentPeer.java:814)
at
java.awt.Component$FlipBufferStrategy.getBackBuffer(Component.java:3623)
at
java.awt.Component$FlipBufferStrategy.updateInternalBuffers(Component.java:3608)
at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:3702)
at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:3684)
at
java.awt.Component$FlipBufferStrategy.getDrawGraphics(Component.java:3676)
at
com.experiment.XFullScreenExclusive$2.run(XFullScreenExclusive.java:130)
at java.lang.Thread.run(Thread.java:619)
This seems strange, as I obviously have created the BufferStrategy quite OK
(this exception came in the middle of the application running!), but somehow in
the minimize-restore rushing, something had gotten lost. But I can't seem to
find a bs.verifyBuffersPresent style method - what did I do wrong here?
Any suggestions for getting FSE without auto-minimizing?
[Message sent by forum member 'stolsvik' (stolsvik)]
http://forums.java.net/jive/thread.jspa?messageID=299090
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
