[FIXED] Enhance native display window API

[princec]

New sizing and positioning API:

- Add setResizable(boolean) / isResizable() flags to Display which should dynamically alter the resizability of the native Display when in windowed non-setParented mode
- Add getWidth() / getHeight()
- Add getX() / getY()
- Add setLocation(int, int)
- Add setSize(int, int)
- Add setBounds(int, int, int, int)
- Add wasResized() which will be processed in update(), and return true if the window size has changed since the last call to update()

New focus management API:
- Add requestFocus() to gain focus
- Add setAlwaysOnTop(boolean)
- Add toFront() and toBack()

Anybody think of anything else?

Cas

[jediTofu]

Sweet thanks!

I still think we should be able to get Mouse x & y negative values off screen without dragging (hidden switch only allows if dragging).  This is unrelated to window API stuff, but it would be useful to windowed games.

[Matthias]

I still think we should be able to get Mouse x & y negative values off screen without dragging (hidden switch only allows if dragging).  This is unrelated to window API stuff, but it would be useful to windowed games.

It is no longer a hidden switch - see allow negative mouse coordinates also with Mouse.next() which is already committed.

But I'm not sure you can get mouse coords outside of the window when you didn't grab the mouse.

[Matzon]

movement outside window is tricky without grab, it requires a system hook - on windows. Not sure about the other.

[kappa]

I still think we should be able to get Mouse x & y negative values off screen without dragging ...  This is unrelated to window API stuff, but it would be useful to windowed games.

Implementation problems aside, extra changes shouldn't be needed for non dragged relative mouse position outside the window, the new API above provides the getX() & getY() of the window. Combined with Java's MouseInfo class you'll be able to get that info. Besides non dragged relative screen position outside the window is an extremely rare use case for games.

[Simon Felix]

How will the requestFocus() stuff work? I don't know of a reliable way on Windows. But functions to make the taskbar icon blink would be nice...

Feature requests for the resize API:
- Specify a minimum/maximum window size
- Specify a fixed aspect ratio (Important!!)

Our game supports only 16:10 (or 16:9, depending on some things determined at startup) resolutions.

[spasi]

It would be great to have all that in LWJGL, but I feel kinda uncomfortable that we have to reinvent the wheel to make it happen. Our windowing code is shitty enough as it is, adding more stuff in there will require a lot of effort and testing (especially to get it to behave properly across platforms). I've always thought that LWJGL should have re-used some existing library for the windowing system, isn't there any lightweight open-source one we can use out there? I also wonder if it would be possible to hook-up our stuff in a JavaFX2 window, that would solve a lot of problems...

[kappa]

nbf from #LWJGL already has the resizeable Display stuff working for Linux, think he implemented it last night. Mac already has resizing built in (as it uses an AWT Frame) and its just a matter of a few methods to expose it (can add that if needed).

Only thing we need now is for someone to bite the bullet and implement it for Windows (any takers?).

@spasi agree with you, but not seen any good options for Java. There's stuff like SWT but its way too heavy. JavaFX has the Prism Toolkit but its unclear whether it will be available directly and even if it is it'll require a cutting edge version of Java (Java 7+ at least) plus it'll probably be a few years before its widespread enough especially on platforms like Mac (will be Java 8+ on there) which pretty much rules it out for now. If we're feeling ambitious we could try some cross project teamwork and work with Jogamp's NEWT!

However LWJGL's Display generally works brilliantly for the limited stuff it does (must say I do like its simplicity). Its pretty battle hardened too being tweaked and patched for many years (it'll be 9 years old at the end of this month), so would be a shame to loose that stability and work.

[spasi]

I agree about the stability and maturity of the current code, but it's in a state that makes adding new features hard. There's very limited documentation and the code is inconsistent between platforms. Also the dependency on Display is very awkward, we can't possibly support multiple displays with the current code base. I tried to do it once and gave up quickly. I was hoping for a clean-up/redesign before adding any features, but it's ok if this RFE can be implemented relatively painlessly.

About Prism, I think JavaFX 2.0 will be supported on JDK6 as well. At least the current beta version requires 6.0u24, which is very reasonable. NEWT would be a nice option as well, as long as it has the features we need, I haven't checked what they've done so far.

[kappa]

well we're almost at 3.0 (two releases away?) would be a great opportunity to do some major API breakage and refactoring.

[badlogic]

Thanks to whoever implements the proposed RFE, and +1 for a redesign of the Display class to support multiple monitors/adapters (please don't ignore the later ). I will happily ditch JOGL for the resizing additions.

[princec]

If you're gonna go that far I'd just say integrate it more properly with AWT and be done with it.

I didn't think some really simple changes like resizable windows is such a tricky thing to do though?

Cas

[CodeBunny]

One thing: if the Display is made resizable (which would be very nice) could it also utilize an event listener API? Example:

Display.addDisplayListener(REFERENCE_TO_OBJECT_IMPLEMENTING_DISPLAYLISTENER);
Display.removeDisplayListener(REFERENCE_TO_DIFFERENT_OBJECT_IMPLEMENTING_DISPLAYLISTENER);

It could then appropriately call all registered listeners in update().

DisplayListener could be an interface with methods such as:

displayResized();
displayMoved();
displayEnteredFullscreen();
displayLeftFullscreen();
displayBPPChanged();
// etc

Alternatively, you could break up the possible types of feedback into different interfaces, such as DisplaySizeListener, DisplayPixelFormatListener, etc.

[kappa]

Just an update on this, decided for now to go for a bare minimum version of princec's resizing api. The following 5 methods have been added to the Display:

1) setResizable(boolean)
2) isResizable()
3) wasResized()
4) getWidth()
5) getHeight()

The mac implementation is done and now part of the nightly builds (so you can already start playing with it, runs really nice and smooth here). nbf is just polishing up the linux implementation and hopefully it should be added soon.

The windows implementation is still up for grabs, if you're interested in attempting it, just post here or pop into the lwjgl irc channel, shouldn't be much work if you're familiar with the Win API. Matzon's working on the windows implementation.

[CodeBunny]

Is there any form of callback? How can I detect if the Display has changed size?

Also, what happens to the viewport when it is set smaller than the full Display but the window is resized?