Removing Windowed support

[Matzon]

After some heavy discussion with several users and developers (yeah - all the action is in #lwjgl on freenode ) running some 500+ lines of verbally abusive language and stuff like that :twisted: - we would like to hear the opinion of the users:

As you might have noticed, Cas posted about some new window features - these were swiftly removed again, since it was deemed not wanted in the LWJGL api.

The reasoning for this is that LWJGL should focus on what it does best, Fullscreen mode. We should therefor restrict the windowed mode to something very basic (if not indeed remove it entirely). If users want to run in windowed mode, they should use SWT og JOGL.

Others were in the opinion that LWJGL should support windowed mode, and features needed by that. However the problem is that many new things might need to be added (user resizing, minimize/maximize/restore etc.) which LWJGL shouldn't bother with and just let JOGL/SWT bother with.

In the future, would you like LWJGL to support windowed mode (and whatever features that are needed to support this) - or wouldn't you mind that it was removed (or limited to current window features)?

[bedelf]

I guess it depends on if you think any windowed games can be valuable in some way.

I personally have never played anything windowed worth spit, so I could really care less.

[elias]

When Matzon says "use JOGL/SWT instead" it's not a question of dropping LWJGL for those. Instead he's talking about our efforts to integrate gl contexts on AWT/SWING (with JOGL or a part of JOGL) and SWT (through whatever it takes to create a SWT context). So all in all, window mode won't go away from LWJGL ever, but instead it will be delegated to other APIs that does a much better job than we can (and will).

Remember, context management is almost orthogonal to the GL API.

- elias

[Orangy Tang]

At the very least I think windowed mode is important as a debugging mode. It may sound trivial but that 2-3 second delay in switching display modes gets tedious when constantly testing-tweeking-retesting etc. Equally I think its a good thing to have for people with flat panel displays to avoid the display trying to emulate a non-native resolution (and so looking like crap).

Having said that, I've managed to get a LWJGL windowed display to quite happily live next to a couple of floating Swing windows fora nice (if somewhat crude looking) level editor. So pinching windowed mode entirly would leave me somewhat high and dry :shock: But I don't really think theres any more functionality that needs adding to windowed mode (would be nice if alpha native cursors worked, but thats not really essencial.

[Numknuf]

If using the gl contexts with awt/swing gives me the same options (or better) as the current windowed mode I won't complain.

But then I 'm not using LWJGL for games...

[tomb]

I vote to keep the simple windowed mode that can be used for debugging.

I would also really like if there was a way too programaticly resize a fullscreen window. Now you have to destory the old window and create a new one. This clears all the texture, display lists etc, wich can be a pain to reload. Is this something that can be added to lwjgl?

[fbi]

If I can express my opinion, my point is that probably removing the native windowing support could eventually raise some other bugs we don't really want to care with  :wink:
I'd vote for keeping it but do not add new features: IMHO LWJGL should run in fulscreen mode when running the game (or the 3D app), in windowed mode for debugging, and integrated with AWT/SWT in case we want to create a 3D app (for example a tool to build worlds, inspect properties of the monsters, NPCs etc.).
AWT I think is important for compatibility reasons because should work fine almost wherever a JVM in installed   whilst SWT can produce compelling UIs, which are like their C++ counterparts, in a cross platform manner.
You know that I'm stuck with the idea of integrating LWJGL and SWT because I think there should be a simpler way for producing a tool than using MFC and Visual C++.

[Fool Running]

Personally, I would like to keep the windowed mode for debugging porposes. :lol:

[greggpatton]

Howdy,

I'm building a game content creation app, a modeler to begin with, and I would like to see continued support for windowed mode.  Since it will be part traditional gui application and part game, I think it will be convenient for the users to sometimes run it in a window instead of fullscreen.

Gregg

[CaptainJester]

Another vote to at least keep it the way it is.  It is very useful for debugging.

[Matzon]

ok, here's the deal.
Whatever we choose to do in the future - we will keep the windowed support.
The real question is if we should ONLY do what we have now, or try to actually make the Window support usefull for anything besides debugging.

We can relatively easy support window movement, size and all sorts of other stuff - however, there might be complexeties with certain OS's  - we don't know. We're therefor arguing that:
a) - we do the windowed stuff, as best as we can
b) - we keep it as we have it now, and let all the fanct window stuff be done using swt or some other window handling binding.

fwiw, we're somewhat split internally. Some of us think that we should keep it as we have now, and let SWT (or JOGL) do all the hard stuff. This would then require you to distribute SWT alongside (~1.5 MB) (can be used for native compilation) or use JOGL and don't use native compilation.
Others think that we should implement most (we don't know *exactly* what is missing, could be a lot - could be simple stuff) of the features that is needed to do window support, so you only need to distribute LWJGL and still have the possibility of native compilation.

Additionally, I am a bit puzzled by how few that has actually stated their oppinion on this matter. It's a fairly big decision IMO.

[spasi]

I've never used non-fullscreen mode. I use my second monitor for debugging .

But I wouldn't mind if LWJGL had a decent windowed support. If people want it for debugging only, then it isn't much work. But if they want something more, shouldn't they be looking for something else (JOGL, SWT) anyway?

What I'd like to see is a list of requested features and a difficulty rating for each one of them. What exactly are we talking about?

[Clockwork]

I would say that completing the window support code would make LWJGL much more flexible. It would be cool to be able to make windowed games too. I've been using windowed mode for debugging, like everyone else, but if I wanted to make a game or tool in windowed mode, I'd rather do it in an api I know and like. I don't know anything about JOGL, but I really like working with LWJGL, and I'd prefer to use it for all my Java 3d needs.

I'm ecstatic to be able to use OpenGL in Java at all, so if that's not what you guys want to do with your project, I'm sure I'll live, but I think it would be very cool to have the flexibility.

[darkprophet]

Personally, i like running multiple games all at once, (of the same game) and to see which is the best at performance, looks...etc. That cannot be done in fullscreen and that would that my beautiful system away from me.

And why do you want to let people go to the evil JOGL anyway? I thought you wanted LWJGL to be the standard for OpenGL bindings in java?

[Mojomonkey]

I run windowed 90% of the time. Removing it would severly screw a few of jME's utilities and applications. I don't mind halting support/ehancement of windowed mode, just please don't remove what you already have.