Re: Fullscreen [was: Re: [gl4java-usergroup] gljMakeCurrentNative free-failed]

[Virgil W. <vir...@ra...>]

> I think it should be a property of GL(A)Canvas. If it would be set to
> 'fullscreen' (eg. 'true') GL's context would be set fullscreen simply
> overlaying everything other (doesn't it works like that in native
> apps?). In this case, the same Java call would call different code under
> different OSes. But this is the whole point in Java portability, isn't
> it? :-) I think GL4J should not bother itself much about AWT components
> because AFAIK they do not support fullscreen, just draw GL on top of
> everything.
> I'm not skilled in any OS GL programming so these are just my wild
> thoughts but I hope it makes sense :-)
>

I guess one other way to do it would be to create something similar to what
Apple did in the java quicktime stuff.
(Take a look at
http://qtj.apple.com/pub/doc/quicktime/app/display/FullScreenWindow.html and
http://qtj.apple.com/pub/doc/quicktime/std/movies/FullScreen.html )
I think this might be essentially what you described.

In this way, though, you actually would get to do normal java development
(and use normal java event handling for things like mousemoves and
keypresses).  The difficulty with this solution is that it has to be done
natively for each platform supported for gl4java.  (Meaning there is a
different way to create top level window on each platform.)

Alternately, one could also write a jni dll that "cheats" and grabs the
pdata class scope member data of the window peer.  This member data actually
just holds the native window handle.  Once you have hold of that, then a
native call to setWindowPos could make any java window or frame a "top
level" window (kind of like the task manager under windows nt/2000... it's
always on top of everything (taskbar included)).  I don't remember what the
equilavent call is under X, but it's there I'm sure.

The disadvantage of the second solution is that it is native and specific to
each platform as well.  It also presumes that some crazy VM vendor didn't go
substantially rewrite the java peer code  (uh hmmmm, I won't name names, but
the comapany name starts with "Micro" and ends in "soft").  Of course, the
jdirect code would just look for something other than pdata if it had to.
Also, some purest might not like the idea of using a jni library (or
jdirect) to cheat and violate java scoping.  After all, pdata is package
scope and we ain't supposed to know that it even exists much less access it.

I kind of like the thing apple did, even though it had to be a royal pain in
the butt.  Their fullscreen class lets you change the screen resolution and
all.  As pointed out, this would be a nice feature as well.  I'm sure all of
the gl purests out there will be quick to point out that none of this has
anything to do with opengl, though.  However, I'd say this would be a sweet
utility for gl support.

I don't know if any of the other java gl bindings have any kind of
fullscreen support or not.  If they don't, the addition of this feature to
gl4java would be an excellent distinguishing feature.  Anybody who wants to
write a game is strongly attracted to this ability.  (Oh wait, I said I was
going to shut up about all of this :)

Virgil Wall