unusual GLWindow behavior on OS X

classic Classic list List threaded Threaded
6 messages Options
ac
Reply | Threaded
Open this post in threaded view
|

unusual GLWindow behavior on OS X

ac
Hi guys,

I'm encountering an issue when using NEWT: if I set the GLWindow size larger than the screen resolution, then the window gets automatically resized to the screen width/height. See this report on how it comes up in Processing:

https://github.com/processing/processing/issues/3401

Is there any way to override this behavior, so the GLWindow has the requested size, even though it doesn't fit in the screen?

Andres
Reply | Threaded
Open this post in threaded view
|

Re: unusual GLWindow behavior on OS X

Xerxes Rånby
ac wrote
Hi guys,

I'm encountering an issue when using NEWT: if I set the GLWindow size larger than the screen resolution, then the window gets automatically resized to the screen width/height. See this report on how it comes up in Processing:

https://github.com/processing/processing/issues/3401

Is there any way to override this behavior, so the GLWindow has the requested size, even though it doesn't fit in the screen?

Andres
Hi Andreas thank you for sharing your use-case and view how you want it to operate: allow the NEWT window to be initialized larger than the screen.

You may want to test the 2.3.2 release candidate from 1 sept 2015 it includes the work of Bug 1186 and 1188 that allows you to set the window non-resizable. 1186 also allows us to specify the flags using a bitfield how we want the NEWT window to behave.
https://jogamp.org/bugzilla/show_bug.cgi?id=1186 
https://jogamp.org/bugzilla/show_bug.cgi?id=1188

Since we have made quite a lot of changes how we handle the state flags on NEWT windows between 2.3.1 and the upcomming 2.3.2 we are very much interested in early feedback before the release.
A comprehensive list of changes can be found here: http://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.3.2

Test build from 1 sept 2015
http://jogamp.org/deployment/archive/master/gluegen_886-joal_612-jogl_1433-jocl_1079-signed/archive/jogamp-all-platforms.7z
ac
Reply | Threaded
Open this post in threaded view
|

Re: unusual GLWindow behavior on OS X

ac
Hi Xerxes,

Thanks for pointing to the test release of 2.3.2. I installed it on Mac, and I can confirm that I can use GLWindow.setResizable() to set the window to non-resizable when the program starts. However, if I try to change the resizable state later on during runtime, the program hangs, but need to look more into it. So far tested on Mac OS X (10.9.5).

Andres
ac
Reply | Threaded
Open this post in threaded view
|

Re: unusual GLWindow behavior on OS X

ac
I have a quick question: is the window capping behavior the default of NSWindow (the native resource wrapped by GLWindow, as far as I understand), or something implemented in JOGL?
Reply | Threaded
Open this post in threaded view
|

Re: unusual GLWindow behavior on OS X

Xerxes Rånby
ac wrote
I have a quick question: is the window capping behavior the default of NSWindow (the native resource wrapped by GLWindow, as far as I understand), or something implemented in JOGL?
I created a junit test to aid discussion and pushed the question to the jogamp IRC.

http://jogamp.org/log/irc/jogamp_20150903050508.html#l107
20150903 13:45:58 <xranby> sgothel: if a user create an enourmous GLWindow lets say size 8000,6000 and use setResizable(false) before making a GLWindow visible, should this window still be auto-resized to fit within the screen limits?
20150903 13:46:29 <xranby> i have created a junit test that expose this issue ( if we expect the window to stay 8000x6000)
20150903 13:47:19 <xranby> the user surely expects the window to stay 8000x6000
20150903 13:56:19 <xranby> sgothel: junit test https://github.com/xranby/jogl/commit/401a01ba31cf6c98d95a67dfa1021af854438044
20150903 14:01:38 <xranby> the above testcase fail with AssertionError: expected:<8000> but was:<1855>
20150903 14:01:52 <xranby> since newt has auto resized the window
20150903 15:00:53 <sgothel> clipping .. is expected
20150903 15:02:09 <sgothel> I assume they use it this way due to some hi-res screenshot or printin?
20150903 15:02:14 <sgothel> printing
20150903 15:02:36 <sgothel> then they shall use offscreen and maybe even tilted-renderer .. as we use for printing
20150903 15:03:03 <sgothel> b/c no platform can guarantee such window sized >> virtual desktop size
Reply | Threaded
Open this post in threaded view
|

Re: unusual GLWindow behavior on OS X

Xerxes Rånby
Xerxes Rånby wrote
ac wrote
I have a quick question: is the window capping behavior the default of NSWindow (the native resource wrapped by GLWindow, as far as I understand), or something implemented in JOGL?
I created a junit test to aid discussion and pushed the question to the jogamp IRC.

http://jogamp.org/log/irc/jogamp_20150903050508.html#l107
20150903 13:45:58 <xranby> sgothel: if a user create an enourmous GLWindow lets say size 8000,6000 and use setResizable(false) before making a GLWindow visible, should this window still be auto-resized to fit within the screen limits?
20150903 13:46:29 <xranby> i have created a junit test that expose this issue ( if we expect the window to stay 8000x6000)
20150903 13:47:19 <xranby> the user surely expects the window to stay 8000x6000
20150903 13:56:19 <xranby> sgothel: junit test https://github.com/xranby/jogl/commit/401a01ba31cf6c98d95a67dfa1021af854438044
20150903 14:01:38 <xranby> the above testcase fail with AssertionError: expected:<8000> but was:<1855>
20150903 14:01:52 <xranby> since newt has auto resized the window
20150903 15:00:53 <sgothel> clipping .. is expected
...
20150903 15:03:03 <sgothel> b/c no platform can guarantee such window sized >> virtual desktop size
I have filed a bugreport to investigate the
[b] discussion if jogl auto-resize in general according to hardware limitations or API enforced limitations.
https://jogamp.org/bugzilla/show_bug.cgi?id=1214