Posted by
Sven Gothel on
May 18, 2010; 11:58am
URL: https://forum.jogamp.org/Feedback-on-Newt-bindings-by-lhkbob-tp823824p826046.html
On Tuesday, May 18, 2010 08:11:11 lhkbob [via jogamp] wrote:
>
> > 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.
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.
>
> >> 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.
>
> 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.
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.
>
> >
> >>
> >> 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.
>
> 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.
all good.
Thank you for your participation!
Cheers, Sven