Newt and native window

OpenGL Development JOGL Development
#1

Hi.

Is it recommended to use the newt packages (most notably GLWindow) for desktop application (eg. game) development?

In particular, what are the chances of:

  • major API changes
  • being moved to other packages/projects (javafx)
  • it becoming closed source/unsupported (com.sun)
    ?

If it isn’t recommended then is it possible using the native window APIs (javax.media) to create a functionally and performantially equivalent (including input events’ impact) implementation without native code at the moment?

#2

Hi Kiena,

well, don’t worry, what is BSD stays BSD :slight_smile: … the license …

  • API: We are about to finalize it and promote it these days
    We may add additional generic input devices to newt,
    like 2 button devices instead of scroll-wheel, etc …
    We will update the GL specs on a maintenance basis,
    no breakage shall be expected …

In general newt is only an example, how things easily can be connected,
the native window (NativeWindow package, which is to be a standard),
and JOGL … or … whatever.

The good thing all three components (NativeWindow -> JOGL + NEWT, AWT, …)
are well abstracted, where you can use any other toolkit - see the javadoc spec.

Yes … the input devices may need more love, so does the binding to macosx.
However, I wouldn’t use AWT anymore and use newt, as we created it
for desktop and mobile devices.

So … within a few weeks, I guess it’s more stable, however, we think
that the current API will not change drastically

#3

Thanks for the answers.

What made me wonder was that newt has its own native nativewindow implementations and that I didn’t find a way how to make full screen the NativeWindow obtained by wrapping an awt Component , yet.

Additionally, the few tests I ran showed that GLWindow doesn’t only have better performace in general, but input processing has a much smaller impact than in AWT(+JOGL)'s case.

Wrapping the component into a native window instead of a Frame may improve input processing too (with less event travel probably), that’s why I asked if similar performace could be achieved by NW+AWT+JOGL.

These implied that NEWT is more usable in general, but since in the JDK’s case com.sun.* packages should be avoided as implementation details or unofficial APIs, I wanted to know what the status of NEWT is.

Now I plan to either use GLWindow or based on Window (and NewtFactory) create a slightly different class.

#4

Fullscreen implementation is satisfied, if you have no decorations and pump up the size to screen size,
all is provided with the NativeWindow interface.
AWT wrapper … right, might be a bug there, needs more love, I will submit the change if you fix it :slight_smile:

Of course, without the AWT overhead and threading issues, leaving it behind, is the choice, if you can.

Well, the package naming convention is based on the following idea/spec:
java*.* packages shall have a JSR standard way, a whole process is behind it … etc
com.sun.* packages are still somehow public, but there is no standardization process behind 'em (lazyness ?)
sun.* or com.sun..impl. are definitely implementation details
So, maybe, if there is a huge resonance to NEWT and if we make it better, we will promote it to something java*.*
However, you can use it, as we do … and don’t need to expect that we change the whole world.

When we are ready for JNLP deployment, you always can choose your desired version,
that’s the benefit of such method.

Mutate GLWindow as you wish, do with it whatever pleases you, sure.
If you are able to enhance it big time in a general way, please give us a chance to backport your changes
so we can better NEWT. The good thing, it doesn’t matter using JOGL, as long you comply with the interface
specification, read the javadoc spec.

For example, if any MacOSX developer is aware of a nice way to allow window creation and even handling
in a thread independent manner … please do so and contribute that code.

Another change, as mentioned, might be an abstraction of InputDevice in NEWT’s Window … you know,
something more generic and pluggable …

#5

Well, some work has been done in the NEWT chapter …

  • True fullscreen for all platforms.
  • Multithreading with JOGL
  • Multiscreen support (as with AWT) … may need more test cases.
  • Seperate even dispatching in NEWT’s Display class for all windows within the current thread,
    you may want to read the NEWT Window comments and the Redsquare demo.

MacOSX with multithreading supported via the com.sun.javafx.newt.util.MainThread launch-class:
java -XstartOnFirstThread -Djava.awt.headless=true com.sun.javafx.newt.util.MainThread demos.es2.RedSquare -GL -GL -GL -GL
which starts 4 threads, each their own window (GLWindow) and rendering thread.
This will work for other platforms as well, since the MainThread class will just handover to the users ‘main class’.
(You may have to get rid of the -X argument)

#6

Regarding fullscreen, does Newt provide a way to change the screen resolution?

EDIT: The invokation of setSize on a GLWindow before setFullscreen has no effect (the window dimensions will become the same as the current resolution) and setting it after setFullscreen only changes the size of the undecorated window.

Since the AWT fullscreen API should be out of the question, is there a way, if these methods are not intended for that purpose?