Posted by
lhkbob on
May 18, 2010; 6:10am
URL: https://forum.jogamp.org/Feedback-on-Newt-bindings-by-lhkbob-tp823824p825521.html
> 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.htmlThanks
>> 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.
>
>>
>> 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.