Feedback on Newt bindings (by lhkbob)

Posted on: May 13, 2010, 12:26:25 am
Posted by: lhkbob
http://www.javagaming.org/index.php/topic,22422.0.html

When I first ported my code over to use JOGL 2 I experimented with the Newt window API but found that it wasn't very stable and had poor event behavior on my Mac.  Because of this (and some things below), I just used the AWT GLCanvas still.  However, now I'm trying out the new version and I would really like to be able to use Newt.

When re-learning its API, here are some things that could use improvement:
1. I have no idea how to change the screen resolution for a fullscreen window.  Setting the window size and then fullscreen does not use the window size as the desired resolution.  This is a feature that's very important for me.
2. Having to specify -XstartOnFirstThread is pretty lame but I understand why it might be necessary
3. Even lamer however is having to use a different main class entry point.
4. The documentation for the native window and newt libraries are non-existent.  I think the API suffers from too much abstraction (when it comes to AbstractX + DefaultX + ImplX for such things as graphics configurations and devices and factories), but also exposes too many low-level handles in an inconsistent manner (sometimes strings and sometimes integers).  It's also not clear who is responsible for locking the surfaces, etc. (#4 is more general and something that I can learn to live with)

With the 2 and 3, I have to document in my engine that anyone which wants to use the JOGL engine implementation has to do special java command line stuff to get it to run without locking up.

Please be specific about (4).

(1) maybe you want to utilize the screen width/height ?

(2) and (3), which is OSX specific, are indeed sub optimum,
and I read a bit of the (new) OSX 10.6 APIs .. in this regards.

However .. if there is somebody out there willing to make NEWT
able to use native multithreading without any 'workaround' -
if this is even possible in regards to OSX underlying architecture.

With regards to using the screen width/height, in Newt's Screen class all I see is a way to get the width and height.  The setters are protected.  If I set the Newt Window's size, it's ignored when I tell it to go to fullscreen mode.  I think this is something that could easily be added to the screen or display classes (I'm not sure which would actually be responsible).

For my 2/3 points, I would be willing to look into it, but it would be helpful if you could point me towards some good literature.

With #4:
The interface NativeWindow has lockSurface(), unlockSurface(), surfaceSwap(), getWindowHandle(), and getSurfaceHandle().  All of these seem more useful for the actual implementations but not something we want most users to see when they just want to make a visible window.

Within Display, there's getFQName(), pumpMessages(), and when creating a Display it's not obvious what's the purpose for having different named displays (or if you can choose your own names).

On Tuesday, May 18, 2010 01:48:01 lhkbob [via jogamp] wrote:
>
> With regards to using the screen width/height, in Newt's Screen class all I
> see is a way to get the width and height.  
Yes .. since we cannot help you with changing the screen dimension,
ie we have no kernel mode setting feature integrated which would exceed NEWTs intention here  :)

> The setters are protected.  If I
> set the Newt Window's size, it's ignored when I tell it to go to fullscreen
> mode.  
Of course .. fullscreen is fullscreen.
But you can create an undecoreated window, and set it's size,
if this is really your intention.

> I think this is something that could easily be added to the screen or
> display classes (I'm not sure which would actually be responsible).
Please make your point, ie describe your use case.

>
> For my 2/3 points, I would be willing to look into it, but it would be
> helpful if you could point me towards some good literature.
Then I would have the solution myself .. I usually just read Apple's APIs
on their website ..
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/cl/NSWindow
http://developer.apple.com/macosx/multithreadedprogramming.html

The last ref may hold something promising .. but I haven't tested it yet.

>
> With #4:
> The interface NativeWindow has lockSurface(), unlockSurface(),
> surfaceSwap(), getWindowHandle(), and getSurfaceHandle().  All of these seem
> more useful for the actual implementations but not something we want most
> users to see when they just want to make a visible window.
I don't know who you think 'we' is here .. but the developer of the
NativeWindow interface intended it to be very low level and actually is the inter-package
and inter-project vehicle to allow abstraction of a native window/surface.
JOGL for example has to call lock/unlock on a NativeWindow implementation
to access the surface handle, but another package/project, eg NEWT provides the implementation.
So I am afraid we just cannot hide it in NEWT.
The only way would be to obscure it a bit, ie not allowing Window to impl NativeWindow
and create yet another layer of abstraction .. but since this wouldn't help at all .. it's useless.

>
> Within Display, there's getFQName(), pumpMessages(), and when creating a
> Display it's not obvious what's the purpose for having different named
> displays (or if you can choose your own names).
This is a matter of API documentation.
I am sure I added something into the git commit log .. maybe I missed to add something
to the method names .. point taken.
However .. as you can read in the source, FQN is the combination of type + user-name,
so the reason was to have a unique display name across types (unique key).
We have test cases where we mix types within one JVM, ie X11 and AWT.

~Sven

> Yes .. since we cannot help you with changing the screen dimension,
> ie we have no kernel mode setting feature integrated which would exceed
> NEWTs intention here  :)
>
 ...
> Of course .. fullscreen is fullscreen.
> But you can create an undecoreated window, and set it's size,
> if this is really your intention.
...
> Please make your point, ie describe your use case.

In many games, they'll run in fullscreen mode and its a pretty common
feature to allow for display mode changes to let the user try to
improve their performance.  I agree with and understand your efforts
to try to keep the Newt and Native window libraries as pure as
possible, but I feel as though display mode changing is a pretty
integral part in a native windowing system.  I can use the AWT windows
with JOGL to get display mode changes but then I suffer from the
performance penalties of using the AWT windows.

>
> Then I would have the solution myself .. I usually just read Apple's APIs
> on their website ..
> http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html
> http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/cl/NSWindow
> http://developer.apple.com/macosx/multithreadedprogramming.html

Thanks

I was thinking that documenting the aspects of the native window that
are useful to the end-user and documenting the methods described above
(and those with similar purpose) as being used by projects/extensions
that require such low-level access.  For example, in the beginning I
struggled to realize that the AbstractGraphicsDevice was not something
that I created or built, but was fetched from the Newt implementation.

I checked the source, I must have missed this, there is a lot of
different areas that I'm trying to familiarize myself with while
debugging my applications.

On Tuesday, May 18, 2010 08:11:11 lhkbob [via jogamp] wrote:
So you are asking for kernel mode settings (KMS),
ie changing the screen resolution :)

Performance you say -  hmm, fill rate etc .., yep there is something here,
I haven't considered yet.
 
On my NEWT enhancement list are:
        - MacOSX multithreading issues
  - attached / detached to parent window state tracking
        - transient parameters (pos,dimension) for modes (attached, detached, fullscreen, ..)
        - transparency test/fix
        - change screen resolution for fullscreen

How about giving your real name, I setup an account for you (wiki/bugzilla)
and assign a few features to you ?
BTW your real name is essential when using your source code, published under the same license!

Then you fork my github repos .. and when you are done with a feature incl junit tests
you ask me to pull/review ?

Would be awesome ..


>
> >
> > Then I would have the solution myself .. I usually just read Apple's APIs
> > on their website ..
> > http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html
> > http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/occ/cl/NSWindow
> > http://developer.apple.com/macosx/multithreadedprogramming.html
>
> Thanks

You are welcome.

yep .. the API documentation needs some love, point taken.
you know the day has only 24 hours.
right now .. we still struggle with our build/test server .. etc ..
and some other high prio features.

all good.

Thank you for your participation!

Cheers, Sven

Sven Gothel wrote

- change screen resolution for fullscreen

I'm interested to know if this has been implemented already ? I've not found any informations to do that with Display/Screen/GLWindow api of recent builds.
If not available, don't worry about that, I can wait (not the top most feature that I need).

Hey jouvieje, this is how a get to Full Screen Mode.

                /**
                 * Full Screen Mode
                 */
                GraphicsEnvironment env = GraphicsEnvironment.

                getLocalGraphicsEnvironment();

                GraphicsDevice device = env.getDefaultScreenDevice();

                device.setFullScreenWindow(myFrame);

Make sure you let me know how this solution worked for you.

Not sure how this could work with newt GLWindow. Obvisouly, setFullScreenWindow could not be used with a GLWindow (and so device.setDisplayMode not as it require a fullscreen window to be set).

On Friday, November 11, 2011 05:07:08 PM jouvieje [via jogamp] wrote:
>
> Not sure how this could work with newt GLWindow. Obvisouly,
> setFullScreenWindow could not be used with a GLWindow (and so
> device.setDisplayMode not as it require a fullscreen window to be set).
>
You are right, it is not. Pixdesk was referring to AWT fullscreen.

Here is how you use NEWT fullscreen (ie. ScreenMode):
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/newt/TestScreenMode01NEWT.java;hb=HEAD

(More ScreenMode tests in the same package)

Cut out from the unit test and brought to some simple order:

 183         GLWindow window = ...
 184         Screen screen  = window.getScreen();
 185
 186         List<ScreenMode> screenModes = screen.getScreenModes();
 187         if(screenModes.size()>1) {
 207           screenModes = ScreenModeUtil.filterByRate(screenModes, smOrig.getMonitorMode().getRefreshRate());
 210           screenModes = ScreenModeUtil.filterByRotation(screenModes, 0);
 213           screenModes = ScreenModeUtil.filterByResolution(screenModes, new Dimension(801, 601));
 217           screenModes = ScreenModeUtil.getHighestAvailableBpp(screenModes);

 221           ScreenMode sm = (ScreenMode) screenModes.get(0);
 223           screen.setCurrentScreenMode(sm);
 224         }
 225         window.setFullscreen(true);

~Sven

Hi

There is something I don't understand. If I use ScreenModeUtil.filterByResolution(), I can choose the proper resolution, it works on any platform, doesn't it?

Pixdesk was referring to AWT fullscreen which is broken on some platforms, be aware of this fact.

I'm quite satisfied by NEWT and please don't remove very low level handles, I use it to mix JOGL with native OpenGL frameworks.

There is a real lack of documentation. Some colleagues prefer asking me some help rather than reading the documentation even for very simple things. I told them to look at the JUnit tests.

When I have some time, I will try my fix concerning the bug 525.

On Saturday, November 12, 2011 01:31:33 PM gouessej [via jogamp] wrote:
>
> Hi
>
> There is something I don't understand. If I use
> ScreenModeUtil.filterByResolution(), I can choose the proper resolution, it
> works on any platform, doesn't it?
As the doc says: "modes with nearest resolution, or matching ones"
So it shall return at least 1 ..

>
> Pixdesk was referring to *AWT fullscreen which is broken on some platforms*,
> be aware of this fact.
>
> I'm quite satisfied by NEWT and please don't remove very low level handles,
> I use it to mix JOGL with native OpenGL frameworks.

Yes ofc, and we need all the abstraction Nativewindow/JOGL/NEWT,
which is the proper architecture to allow platform agnostic interfacing between all of them
for all platforms (X11, Windows, OS X, Android, OpenKODE, ..).

>
> There is a real lack of documentation. Some colleagues prefer asking me some
> help rather than reading the documentation even for very simple things. I
> told them to look at the JUnit tests.
Indeed .. guess we have to put a blinking banner in the FAQ or front page :)

Source code and examples _ARE_ IMHO the best documentation ever ..
plus our little API javadoc.
While adding OS X offscreen-layer-surface stuff, I can tell you .. the lack of both
was quite frustrating.

>
> When I have some time, I will try my fix concerning the bug 525.
Perfect.

I will send a few more replies .. and head out to my 2 day-weekend :)

Hopefully next week, I can catch up with all the other work,
since OS X is almost done now.

~Sven

Hi Sven, What do you mean when you mention the Android platform? What can you do with JOGL on Android? I'm really not aware of anything about it. I usually go directly to the Android's Open GL implementation.

Thanks sven, works great with ScreenMode :)
I was very close to use it but I thought it was only about screen rotation, after looking it again everything was perfectly detailled in the javadoc !

@pixdesk: check sven's blog, there's some info about jogl on android.