New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P2D and P3D windows behave strangely when larger than the screen size #3401

Closed
codeanticode opened this Issue Jun 18, 2015 · 31 comments

Comments

Projects
None yet
6 participants
@codeanticode
Member

codeanticode commented Jun 18, 2015

JOGL's GLWindow has a peculiar way of handling sizes that are larger than the display: if the window's height surpasses the display's height, then the window's height is capped at the display's. In addition to that, the canvas is attached to the lower left corner so the contents come out of the viewport from the top. Haven't found a way in JOGL to chance this behavior and make it consistent with the rest of the renderers.

To check by yourself, run this code making sure that the height is larger than the current display's height:

void setup() {
  size(512, 1000, P3D);
}

void draw() {
  background(150);
  line(0, 0, width, height);
  line(0, height, width, 0);
}

you should be getting something like this:

image

@monkstone

This comment has been minimized.

Show comment
Hide comment
@monkstone

monkstone Jun 20, 2015

void setup() {  
}

void draw() {
  background(150);
  fill(255);
  ellipse(width / 2, height / 2, 300, 1000);
  stroke(0);
  line(0, 0, width, height);
  line(0, height, width, 0);  
}

void settings(){
 size(512, 2000, P3D);
}

Spooky weird, kind of wonderful though. On linux (Mint-17.1) original sketch refuses to run, so I modified as above. Window then displays to maximum available height (but scaled) ie lines to corners. Same true when I maximise sketch (scaling but does no affect ellipse screen 1920x1020)..

monkstone commented Jun 20, 2015

void setup() {  
}

void draw() {
  background(150);
  fill(255);
  ellipse(width / 2, height / 2, 300, 1000);
  stroke(0);
  line(0, 0, width, height);
  line(0, height, width, 0);  
}

void settings(){
 size(512, 2000, P3D);
}

Spooky weird, kind of wonderful though. On linux (Mint-17.1) original sketch refuses to run, so I modified as above. Window then displays to maximum available height (but scaled) ie lines to corners. Same true when I maximise sketch (scaling but does no affect ellipse screen 1920x1020)..

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Jul 16, 2015

Contributor

Can't reproduce. It works as expected on my Windows 8.1 64bit. Window size is capped by the screen size, size of the sketch is automatically adjusted, width and height correctly reflect the actual size of the sketch.

When the size() is in setup() and width or height is greater than the size of the screen, the sketch freezes and I get IllegalStateException: size() cannot be used here, see http://processing.org/reference/size_.html, but in settings() it works with all sizes.

Contributor

JakubValtar commented Jul 16, 2015

Can't reproduce. It works as expected on my Windows 8.1 64bit. Window size is capped by the screen size, size of the sketch is automatically adjusted, width and height correctly reflect the actual size of the sketch.

When the size() is in setup() and width or height is greater than the size of the screen, the sketch freezes and I get IllegalStateException: size() cannot be used here, see http://processing.org/reference/size_.html, but in settings() it works with all sizes.

@benfry benfry changed the title from JOGL handles large windows differently to P2D and P3D windows behave strangely when larger than the screen size Aug 12, 2015

@benfry benfry added the known label Aug 12, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 12, 2015

Member

Adding “known” tag because this is listed in the “known issues” section in the wiki. When this bug is fixed, it should be removed there.

Member

benfry commented Aug 12, 2015

Adding “known” tag because this is listed in the “known issues” section in the wiki. When this bug is fixed, it should be removed there.

@benfry benfry added high and removed enhancement labels Sep 1, 2015

@benfry benfry added this to the 3.0 final milestone Sep 1, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 1, 2015

Member

JAVAFX does automatic window resizing as well when width/height are larger than the screen resolution, but the sketch's width/height variables are properly set to the actual resolution. I will reproduce that behavior on the GL renderers, at least until JOGL's changes the window behavior. I just wrote a post on their forum about this.

Member

codeanticode commented Sep 1, 2015

JAVAFX does automatic window resizing as well when width/height are larger than the screen resolution, but the sketch's width/height variables are properly set to the actual resolution. I will reproduce that behavior on the GL renderers, at least until JOGL's changes the window behavior. I just wrote a post on their forum about this.

@xranby

This comment has been minimized.

Show comment
Hide comment
@xranby

xranby Sep 2, 2015

Contributor

I can not reproduce this bug using Ubuntu 14.04.3 LTS 64bit Linux.
The window gets re-sized automatically if larger than the screen
however it is scaled correctly, the lines go from the corners of the window.

Is this bug confined to MacOS X?

Contributor

xranby commented Sep 2, 2015

I can not reproduce this bug using Ubuntu 14.04.3 LTS 64bit Linux.
The window gets re-sized automatically if larger than the screen
however it is scaled correctly, the lines go from the corners of the window.

Is this bug confined to MacOS X?

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 2, 2015

Member

I believe it affects Windows as well, @JakubValtar could you confirm this?

Member

codeanticode commented Sep 2, 2015

I believe it affects Windows as well, @JakubValtar could you confirm this?

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Sep 2, 2015

Contributor

@codeanticode Nope, we talked about it yesterday, it's a Mac thing.

Contributor

JakubValtar commented Sep 2, 2015

@codeanticode Nope, we talked about it yesterday, it's a Mac thing.

@benfry benfry added the macosx label Sep 2, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 4, 2015

Member

@benfry @JakubValtar: capping the window size to the screen resolution seems to be the default behavior for JAVA2D in Windows, as well as JAVAFX on Windows and Mac.

We expect to be able to create windows of arbitrary size because it was possible with AWT on Mac before, but now I'm wondering if we should normalize this behavior across all renderers and platforms and make capping as the default.

Member

codeanticode commented Sep 4, 2015

@benfry @JakubValtar: capping the window size to the screen resolution seems to be the default behavior for JAVA2D in Windows, as well as JAVAFX on Windows and Mac.

We expect to be able to create windows of arbitrary size because it was possible with AWT on Mac before, but now I'm wondering if we should normalize this behavior across all renderers and platforms and make capping as the default.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 5, 2015

Member

No, let's not limit everywhere if it's an OS + renderer problem. We should just fix the JOGL + OS X case seen here.

Member

benfry commented Sep 5, 2015

No, let's not limit everywhere if it's an OS + renderer problem. We should just fix the JOGL + OS X case seen here.

@xranby

This comment has been minimized.

Show comment
Hide comment
@xranby

xranby Sep 6, 2015

Contributor

I have filed a bugreport to investigate
[a] the macosx GLWindow gets incorrectly auto-resized, content is rendered outside the window
https://jogamp.org/bugzilla/show_bug.cgi?id=1214

It would be very good if someone with MacOSX can copy and change one of the JOGL junit tests and make it demonstrate the issue without using processing 3.

Contributor

xranby commented Sep 6, 2015

I have filed a bugreport to investigate
[a] the macosx GLWindow gets incorrectly auto-resized, content is rendered outside the window
https://jogamp.org/bugzilla/show_bug.cgi?id=1214

It would be very good if someone with MacOSX can copy and change one of the JOGL junit tests and make it demonstrate the issue without using processing 3.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 18, 2015

Member

@codeanticode This is a stopper for 3.0 final; don't we have a workaround to deal with the OS X case?

Member

benfry commented Sep 18, 2015

@codeanticode This is a stopper for 3.0 final; don't we have a workaround to deal with the OS X case?

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 18, 2015

Member

I have a potential workaround for 3.0: inside initWindow() check if sketchWidth/Height is greater than displayWidth/Height, if so, resize the sketchWidth/Height to sketchWidth/Height. However, I would also need to subtract the sum of the height of the apple menu bar and the height of the window top bar. I can get the latter from window.getInsets().getTopHeight(), but don't know how to obtain the height of the apple menu bar. Can we add a getter to JAppleMenuBar for that purpose?

Member

codeanticode commented Sep 18, 2015

I have a potential workaround for 3.0: inside initWindow() check if sketchWidth/Height is greater than displayWidth/Height, if so, resize the sketchWidth/Height to sketchWidth/Height. However, I would also need to subtract the sum of the height of the apple menu bar and the height of the window top bar. I can get the latter from window.getInsets().getTopHeight(), but don't know how to obtain the height of the apple menu bar. Can we add a getter to JAppleMenuBar for that purpose?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 19, 2015

Member

I was hoping that we could just get the window's dimensions after it's been resized by the OS, rather than guess what the window was going to be resized to (the calculations you describe). Can we not do that?

Member

benfry commented Sep 19, 2015

I was hoping that we could just get the window's dimensions after it's been resized by the OS, rather than guess what the window was going to be resized to (the calculations you describe). Can we not do that?

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 19, 2015

Member

I was hoping the same thing, but GLWindow reports the original size, even though it has been capped to fit the screen. I mentioned this in the discussion in the JOGL bug tracker, but haven't heard back anything yet.

@xranby do you any updates on this issue? It is a stopper for 3.0 final, but I'm having a difficult time finding a reasonable workaround.

Member

codeanticode commented Sep 19, 2015

I was hoping the same thing, but GLWindow reports the original size, even though it has been capped to fit the screen. I mentioned this in the discussion in the JOGL bug tracker, but haven't heard back anything yet.

@xranby do you any updates on this issue? It is a stopper for 3.0 final, but I'm having a difficult time finding a reasonable workaround.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 21, 2015

Member

I implemented a method in JOGL's native code that resizes the rendering window in OS X when it exceeds the screen size. Not sure if it will be included in JOGL's main repo, at least as it is and by the time we release 3.0 final. If not, as a last resort we could build our own modified jar files to bundle with Processing.

Member

codeanticode commented Sep 21, 2015

I implemented a method in JOGL's native code that resizes the rendering window in OS X when it exceeds the screen size. Not sure if it will be included in JOGL's main repo, at least as it is and by the time we release 3.0 final. If not, as a last resort we could build our own modified jar files to bundle with Processing.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 21, 2015

Member

I don't suppose you've heard anything about the next planned release date for JOGL?

Member

benfry commented Sep 21, 2015

I don't suppose you've heard anything about the next planned release date for JOGL?

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 21, 2015

Member

Nothing so far. I haven't received any replies in the bugtraker or the forum. By looking at the objectives page for their next stable release, one would say is near. I will try to get some info on their IRC channel.

Member

codeanticode commented Sep 21, 2015

Nothing so far. I haven't received any replies in the bugtraker or the forum. By looking at the objectives page for their next stable release, one would say is near. I will try to get some info on their IRC channel.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 21, 2015

Member

Ok, I'll remove the 3.0 final tag since it's out of our control.

Member

benfry commented Sep 21, 2015

Ok, I'll remove the 3.0 final tag since it's out of our control.

@benfry benfry removed this from the 3.0 final milestone Sep 21, 2015

@benfry benfry added the cantfix label Sep 21, 2015

@xranby

This comment has been minimized.

Show comment
Hide comment
@xranby
Contributor

xranby commented Sep 25, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 25, 2015

Member

Good to hear! Thanks for the update.

Member

benfry commented Sep 25, 2015

Good to hear! Thanks for the update.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 25, 2015

Member

We would need to update to an RC of JOGL 2.3.2, or the final release if it is ready by the time 3.0 comes out. Should we add the update to 2.3.2 as an issue in the 3.0 milestone?

Member

codeanticode commented Sep 25, 2015

We would need to update to an RC of JOGL 2.3.2, or the final release if it is ready by the time 3.0 comes out. Should we add the update to 2.3.2 as an issue in the 3.0 milestone?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 25, 2015

Member

I think we need to get 3.0 out w/o the 2.3.2. As far as I understand it, there isn't a committed release date for 2.3.2, nor is it fair for us to harass them for one or blame them for holding up our 3.0.

Member

benfry commented Sep 25, 2015

I think we need to get 3.0 out w/o the 2.3.2. As far as I understand it, there isn't a committed release date for 2.3.2, nor is it fair for us to harass them for one or blame them for holding up our 3.0.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 25, 2015

Member

Of course not, what I was thinking was to open an issue on updating to 2.3.2, either to an RC, or the final release in case it is available. My point would be that it is worth updating to even an RC (I have been using the latest ones and did not have any problems) to fix this issue in 3.0 final, since it has been confusing many people. Otherwise, we could just update jogl whenever the 2.3.2 final comes out, and make into a 3.x release.

Member

codeanticode commented Sep 25, 2015

Of course not, what I was thinking was to open an issue on updating to 2.3.2, either to an RC, or the final release in case it is available. My point would be that it is worth updating to even an RC (I have been using the latest ones and did not have any problems) to fix this issue in 3.0 final, since it has been confusing many people. Otherwise, we could just update jogl whenever the 2.3.2 final comes out, and make into a 3.x release.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 25, 2015

Member

But we'd decided not to include RC binaries if we're about to replace them shortly after. Though if we think this is bad enough, maybe we should revisit that decision.

Member

benfry commented Sep 25, 2015

But we'd decided not to include RC binaries if we're about to replace them shortly after. Though if we think this is bad enough, maybe we should revisit that decision.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 25, 2015

Member

Ok, fair enough. We said before this is a stopper for 3.0, that's why I thought that making an exception to update to RC binaries could be desirable. But maybe the issue is not so serious after all, and @shiffman and @REAS could weight in based on their experience with students: do you think this should be fixed for 3.0 final, or could it wait?

Member

codeanticode commented Sep 25, 2015

Ok, fair enough. We said before this is a stopper for 3.0, that's why I thought that making an exception to update to RC binaries could be desirable. But maybe the issue is not so serious after all, and @shiffman and @REAS could weight in based on their experience with students: do you think this should be fixed for 3.0 final, or could it wait?

@REAS

This comment has been minimized.

Show comment
Hide comment
@REAS

REAS Sep 25, 2015

Member

I think this issue is an inconvenience and unfortunate, but it shouldn't stop our release. It's great to hear it's fixed in JOGL and it will be great to incorporate it when the time is right.

Member

REAS commented Sep 25, 2015

I think this issue is an inconvenience and unfortunate, but it shouldn't stop our release. It's great to hear it's fixed in JOGL and it will be great to incorporate it when the time is right.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 26, 2015

Member

Ok, sounds good. I will keep an eye on the JOGL releases, so we can incorporate the latest stable version as soon as it becomes available.

Member

codeanticode commented Sep 26, 2015

Ok, sounds good. I will keep an eye on the JOGL releases, so we can incorporate the latest stable version as soon as it becomes available.

@xranby

This comment has been minimized.

Show comment
Hide comment
@xranby

xranby Sep 28, 2015

Contributor

http://forum.jogamp.org/Release-2-3-2-and-Bugzilla-Entries-td4035393.html

Dear All, updated release wiki page for 2.3.2:
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.3.2

Contributor

xranby commented Sep 28, 2015

http://forum.jogamp.org/Release-2-3-2-and-Bugzilla-Entries-td4035393.html

Dear All, updated release wiki page for 2.3.2:
https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.3.2

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Sep 28, 2015

Member

Hi Xerxes, thanks so much for the updates and all the hard work!

I will test the RCs from Processing and will report back in the issues opened in the jogl bug tracker.

Member

codeanticode commented Sep 28, 2015

Hi Xerxes, thanks so much for the updates and all the hard work!

I will test the RCs from Processing and will report back in the issues opened in the jogl bug tracker.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Sep 28, 2015

Member

Great, so that'll be perfect for (the inevitable) 3.0.1. Looking at Tuesday or Wednesday for 3.0 final.

Member

benfry commented Sep 28, 2015

Great, so that'll be perfect for (the inevitable) 3.0.1. Looking at Tuesday or Wednesday for 3.0 final.

@benfry benfry added this to the 3.0.1 milestone Sep 30, 2015

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Oct 10, 2015

Member

9a71778 fixes this.

Member

codeanticode commented Oct 10, 2015

9a71778 fixes this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment