Creating a window?

[cfmdobbie]

I must be going mad - I just can't find a way of creating an arbitrarily-sized window in the recent unofficial releases!  I understand DisplayModes, and creation of displays with or without a fullscreen flag, but of course I can't create a DisplayMode object myself, and it looks like that's the only way context dimensions get into the system these days.

So, what am I missing?

[cfmdobbie]

The answer is... I'm not missing anything at all!  Chat log follows (edited):

   cfmdobbie   Hi Elias, got a quick question:
   cfmdobbie   How do I create an arbitrarily-sized context?
   cfmdobbie   Windowed, I mean
   elias_naur   erh
   elias_naur   you can't,anymore
   cfmdobbie   Ah
   cfmdobbie   That's... a little annoying
   elias_naur   could be, depends on your usage
   elias_naur   we don't support resizing anyway...
   cfmdobbie   Don't care about resizing, I'm just after a window that isn't 4:3
   cfmdobbie   Specifically, 464x384 pixels.
   elias_naur   what for?
   cfmdobbie   For a simple little game, bit of a diversion really.
   cfmdobbie   It'd be intrusive to go fullscreen, so I want windowed,
   cfmdobbie   But I don't want to have a 4:3 window
   elias_naur   but why the exact odd window size?
   cfmdobbie   Lots of games have specific non-4:3 window sizes
   cfmdobbie   Think solitaire, winmine etc
   elias_naur   myes
   cfmdobbie   I was rather hoping I'd missed something - didn't want to have to change to JOGL just for context creation
   cfmdobbie   :-/
   elias_naur   what about the SWT bindings?
   elias_naur   they should be reasonable usable with LWJGL last time I heard
   cfmdobbie   I don't seem to have them in any of the releases I have here...
   elias_naur   no, they're still "unofficial"
   elias_naur   but people seem to have success building and using them
   cfmdobbie   Ugh
   cfmdobbie   I'm not too keen on having to bother with the whole 150+MB compiler download
   cfmdobbie   Righto, thanks anyway!
   elias_naur   ok
   elias_naur   I can see you're not happy with the things as they are now :-)
   cfmdobbie   Well, it was rather handy before, nice and convenient.
   elias_naur   but LWJGL windowed mode is not really meant to be anything than "fullscreen that cooperate with other desktop stuff"
   elias_naur   SWT and other "real" toolkits are meant to provide real windows, with controls, resizing and all that
   elias_naur   maybe you could post a request on the boards,and we'll come up with a nice compromise
   cfmdobbie   Well, yeah. But on the other hand, LWJGL 0.9 does what I want, as of 1.0 it won't.
   cfmdobbie   That a bit of a shame.
   elias_naur   maybe we should just make the DisplayMode constructor public
   elias_naur   after all, the setDisplayMode could fail
   elias_naur   that's what I meant about a compromise
   elias_naur   restore your wanted functionality in a way compatible with the new Display :-)
   cfmdobbie   Well, not really.
   cfmdobbie   I'm not playing with "display modes" at all - the syntax would be all b0rked
   elias_naur   yes, but then the name should be changed
   elias_naur   the DisplayMode is used for the windowed mode too
   cfmdobbie   Maybe DisplayMode -> ContextSpecification, include PixelFormat and fullscreen flag? That would make more sense, at least.
   cfmdobbie   Yeah, I think using DisplayModes for windowed mode is b0rked as well
   cfmdobbie   :-P
   cfmdobbie   You can create a windowed context, but only if your hardware is capable of making a fullscreen window of the same size? Meh.
   elias_naur   so I don't think PixelFormat and fullscreen flag should be included in the DisplayMode
   elias_naur   because DisplayMode is enumerated
   cfmdobbie   Okay. Hmm.
   elias_naur   anyway, we should continue this on the boards
   elias_naur   toget some input on it all
   cfmdobbie   Righto, I'll tag it onto the end of my question.

[cfmdobbie]

The current syntax for creating windowed contexts is confused.  You need to play with DisplayModes, which should be irrelevant outside of fullscreen applications.  I'm not even sure, from looking at Display.java, how to create a window that doesn't fill the whole screen anyway!

My opinion:

A simple windowed mode is quick and convenient.  Using JOGL or SWT to create a context is possible, but it seems like overkill when LWJGL is able to do it.  I'm not after any advanced functionality, just what I could already do in LWJGL 0.9.  I suggest a rethink of the way contexts are created.

I should not be passing in colour depths more than once for the same job.  What happens if I request 32-bit colour in a 16-bit display mode?  Why am I even given the option of specifying a window with a colour depth different from the current desktop colour depth?  Those two situations are nonsensical, and the API should not allow them to occur.

The way that Display currently works seems to me to be a bad idea - and this opinion can be justified solely on the complexity of the code that makes it all happen.  Reading Display.java is hard work, and I don't imagine that maintenance of it is any easier.

I believe Display should contain two different forms of context creation function, e.g. createFullscreenContext() and createWindowedContext().  I should not be passing in a fullscreen flag - the difference between fullscreen and windowed modes is much more complex than a boolean can express!

I think DisplayModes need to be hidden deep within the API - There's no real reason to allow arbitrary video mode switches.  If the developer wants to pick a display mode from a list, fine.  If they want to attempt to use one for their fullscreen context, fine.  Those are functional uses for display modes.  setDisplayMode is not - it's a low-level function that the developer shouldn't be concerned with.

First things first, what do you all think of the above?

[elias]

setDisplayMode does not switch mode in itself. It sets the mode you want to use for the context. If the Display is not created, the given mode is simply stored for later use. If the Display is created, the mode is switched to the desired mode and the context is resized. Same goes for setFullscreen().

You're not required to pass in the color depth twice, either. It is documented that the bpp part of PixelFormat is ignored in Display.create().

 - elias

[garazdawi]

Yes, if windowed mode is to be availabel thourgh lwjgl it should be possible to set whatever size one wants. The windows doesn't have to be resizeabe though IMO, but you should be able to choose to have a window that tetris clones will fit into perfectly without desktop space wastage...

[aldacron]

I've never understood the reluctance to fully support windowed mode, anyway. Gamers are accustomed to games which allow them to toggle between fullscreen/windowed mode.  On Windows it's not difficult to implement, and I imagine it would only be easier on Linux and Mac since, as I understand it, the OpenGL context doesn't get trashed when switching. This idea that Windowed mode is only for development has really been the only thing I dislike about LWGL.

And the idea that we should have to go through SWT for a Windowed mode game is absurd since it can be built right into LWJGL with full input support and without the extra requirement of shipping the SWT libraries. I just don't get it.

[Matzon]

The reason for not supporting full windowed mode, is because of the complexities!

resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...

[aldacron]

resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...

All of those events are easily handled through the window system's event manager, yes? There are two things that need to be done dependeing upon the specific event:

1) let the app know that the scene needs to be resized on resize/move events, and

2) activate/deactivate the app on other events.

Both cases can be handled with a listener interface that must be registered during initialization. This is basic stuff that I started doing on Windows in the DDraw days. I'm just not seeing the difficulty here, as long as you are only reacting to Window events and not providing a way to create them programmatically.

What's more difficult, as I see it, is dealing with toggling between fullscreen/windowed mode on Windows, since the gl context gets smashed (aauming the Window is destroyed and recreated) and all active textures/states need to be reloaded/reset. This, however, is an app-specific problem which again can be handled via the same listener. LWJGL can provide a isResetRequired method which returns true on all platforms where the context is smashed on a fullscreen toggle. And the toggling itself need not be implemented in the API, but again could be app-specific (ie destroying the current display and recreating in the proper mode).

[elias]

resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...

All of those events are easily handled through the window system's event manager, yes? There are two things that need to be done dependeing upon the specific event:

1) let the app know that the scene needs to be resized on resize/move events, and

2) activate/deactivate the app on other events.

Both cases can be handled with a listener interface that must be registered during initialization. This is basic stuff that I started doing on Windows in the DDraw days. I'm just not seeing the difficulty here, as long as you are only reacting to Window events and not providing a way to create them programmatically.

Well, you're talking Windows here. As matzon said, the job is harder once you move to multiple platforms. Look how hard it is for SUN to maintain consistent behaviour in AWT/Swing. But the important point is that it is simply not that important - if you need special windowing, SWT/AWT is much better at it than us.

What's more difficult, as I see it, is dealing with toggling between fullscreen/windowed mode on Windows, since the gl context gets smashed (aauming the Window is destroyed and recreated) and all active textures/states need to be reloaded/reset. This, however, is an app-specific problem which again can be handled via the same listener. LWJGL can provide a isResetRequired method which returns true on all platforms where the context is smashed on a fullscreen toggle. And the toggling itself need not be implemented in the API, but again could be app-specific (ie destroying the current display and recreating in the proper mode).

Where did you get that from? In fact, fullscreen/windowed toggling works fine in LWJGL CVS code on win32 (and linux) right now.

- elias

[cfmdobbie]

What I'm getting at is that in LWJGL 0.9 we used to be able to create arbitrarily-sized windows, but in current CVS we cannot.  In current CVS you can create windows, but only at a size that corresponds to a video mode that the 3D hardware allows - which makes no logical sense whatsoever.

I'm currently intending to step back to a previous version to fix this, but would be just as happy if you integrated the SWT binding to make it "official", and released a new version ASAP.  It's been a while since the last official release, and there's so much in the API that would be useful to use, but if it's not possible to create non-4:3 windows, that's just not an option.

I don't have the time nor the bandwidth to download 150-200MB of compiler just so I can draw a square window. :roll:

[elias]

For now, it has been fixed by adding a public DisplayMode constructor. And a new release is imminent

- elias

[aldacron]

Well, you're talking Windows here. As matzon said, the job is harder once you move to multiple platforms. Look how hard it is for SUN to maintain consistent behaviour in AWT/Swing. But the important point is that it is simply not that important - if you need special windowing, SWT/AWT is much better at it than us.

You're missing my point. There's no need for special windowing. I agree that SWT/AWT are the better solution in that case. Sun's difficulties with AWT have nothing to do with this. All I'm talking about is having the ability to create a Window which can be any size, which can be resized by the user (or not), and nothing more. In other words, the same functionality offered by SDL (actually less, since SDL also has the ability to hook into system window messages). I'm not talking about supporting child controls and all of that, which is inconsistent from platform to platform.

IIRC Cas said before (more than once) that windowed mode was supported for use in development. All I'm asking is that windowed mode be given as much importance as fullscreen mode. People *will* complain about fullscreen only games, particularly those who play them in the office  (I'm thinking from an indie business perspective here).

Where did you get that from? In fact, fullscreen/windowed toggling works fine in LWJGL CVS code on win32 (and linux) right now.

Yes, toggling has worked in LWJGL since I first used it. I haven't looked at CVS in a while, but if things are as they were before then toggling is done manually by resetting the display mode, destroying and recreating the window. Unless there's a toggle method now? But the opengl context will still get clobbered when the window is destroyed, a new one will be recreated, and all textures will need to be uploaded to the card again (unless things have suddenly changed on Windows).

My intent was to say that this is the most difficult and inconsistent aspect of supporting cross-platform windowed mode, in my view.

[elias]

Well, I think resizing is special, because it is only applicable to windowed mode. And don't take Cas too seriously on the issue, as some of us crazy danes spoiled his grand debug-only plan a long time ago

And yes, you can now setFullscreen(boolean) or setDisplayMode(mode) on Display and not loose your context.

- elias