Hello folks
I’m using a PC and visual studio, and toggling between a window and full screen using ofToggleFullscreen.
It looks as though when in window mode, there are pixels cropped out of the window to the top left. About 10-15 in the x axis from the left and about 40-60 in the y axis from the top. Small, but enough to have caused me a headache with setting out from the top left corner.
Does anyone know what causes this and how to stop it?
Thanks
S
This seems like a really basic issue to me, is there a simple fix that I don’t know about? Surely 0,0 for drawing and interaction should always be within the window?!
I realise that I could just work out the difference and translate by that, but it is still causing me some really buggy setout and interaction issues when using ofxDatGui…
Can anyone help?
S
As in the note I posted to this other question , it seems to me this is not the case. That is, 0,0 should be in the upper-left corner for 2-D drawing with z = 0.
But I think things drift a bit relative to the screen plane when they have a z coordinate, or perhaps for other reasons.
No, there’s no z coordinates involved.
I’ve tried with just drawing a rectangle from 0,0, and after toggling from fullscreen to window, the rectangle is about 38 pixels displaced off the screen.
Oh you are toggling it while the program is running… do you start your program in full-screen or in windowed mode?
Hmm, I just added toggling to one of my 2D games, and it doesn’t do that to me, neither when I start in windowed or full screen mode. I wonder what is different between your program and mine?
I’m using a really basic test example; just setup, drawing a square at 0,0, and a bool to toggle the full screen mode.
It doesn’t make any difference wether the startup is full screen or not; the square is in the correct position in full screen mode and about -10,-38 from the top left location when not.
Meanwhile ofGetMouseX() etc returns the correct coordinates ie 0,0 at top left in both modes
Huh. I moved my test to a simple app too, and I still get my rectangle at 0,0 in the upper-left corner when I toggle full screen.
Maybe it’s because I’m running on Windows 7 and you’re running on another version?
Nope, Windows 7, OF 0.10.1, and VS 2017
That’s the same as me. Again, I wonder why we’re seeing different results!
So… I made a new blank OF project with OF Project Generator, and the only changes to it I made were in ofApp.cpp:
//--------------------------------------------------------------
void ofApp::draw(){
ofSetColor(ofColor::aliceBlue);
ofDrawRectangle(0, 0, 3, 3);
}
//--------------------------------------------------------------
void ofApp::keyPressed(int key){
switch (key)
{
case '[':
ofToggleFullscreen();
break;
default:
break;
}
}
This puts a small square at 0,0, and if you press the [ key, it will toggle window and full screen mode. On my computer, the square appears there even after toggling back and forth. I’d be curious if you see a different result?
I already said I was trying something that basic. I’m not even using a key type, just the following:
void ofApp::draw(){
ofSetColor(0);
ofDrawRectangle(5,5,50,50);
}
void ofApp::update(){}
void ofApp::keyPressed(int key){
ofToggleFullscreen();
}
As I said before, still the same issue:
Even more odd; I thought I’d check the lower edge of the window in terms of drawing coordinates.
So I tried to draw two circles.
void ofApp::draw(){
ofSetColor(0);
float p = ofGetHeight()-17;
ofDrawCircle(100,p,10,10);
ofSetColor(255);
ofDrawCircle(100,p,2,2);
So you’d expect to see two circles with an offset of 17 from the bottom edge, one small white one at the centre of a black one, right?
Wrong:
What the funk is going on here? Everything is basically broken if I can’t rely on the draw coordinates.
In the circle case, the third parameter isn’t width but z coordinate. The 2D effect only works when everything is at z=0. If you set the third parameter in each ofDrawCircle to 0, the white circle should be centered in the black one. Otherwise you get a perspective effect.
What I don’t get is why if I do this:
void ofApp::draw(){
ofSetColor(0);
ofDrawRectangle(5, 5, 50, 50);
ofSetColor(ofColor::aliceBlue);
ofDrawRectangle(0, 0, 3, 3);
ofSetColor(0);
float p = ofGetHeight() - 17;
ofDrawCircle(100, p, 0, 10);
ofSetColor(255);
ofDrawCircle(100, p, 0, 2);
}
I get this:
But you presumably get your display cut off by the Windows framing.
I notice your Windows framing has rather a different styling from mine, which I don’t recognize. Perhaps your desktop settings are not being understood well by OF? Is the size of the window you get including the framing the same size you request in the program, or is it larger (to include the framing outside) like mine is?
Aha ok, seems I’ve been using ofCircle wrong for a while then! I thought they might be ellipse declarations.
That fixed the circle disparity, phew. But now I have this:
Interesting points in window mode:
the circles are definitely not aligned to where they should be; -17 should bring them well away from that edge as per yours
with a smaller window size there is clear pixel distortion going on, no? The larger black circle is elongated in the y axis
black rectangle well off window as per original issue
mouse X,Y reports the top left as 0,0, and bottom right as 245,245 when I’m requesting the window size as 250,250
Hmmmm.
Might there be something hidden in VS properties??
Thanks for your thoughts on this, appreciate the help!
S
Edit: n.b. I’m on Windows 10 btw not 7, my bad
Hmm. Putting your screenshot in Photoshop, I see the size of the window under the title bar as 246 x 246, which matches what your mouse X,Y reports.
When I tell my sample to use a 250 x 250 window… I get a 250 x 250 window with the Windows 7 framing outside that area.
It looks like your window is 250 wide but includes 2 pixels of frame on all sides but the top, which since the window is 289 high including the frame and seems to cut off all but 26 rows of your 50 x 50 rectangle, seems to overlay the top of the display window another 22 pixels or so.
That does seem rather irregular, since yes that does mean that it’s not just overlaying the edges with the frame, and it’s not just taking a thick strip off the top, but it’s also stretching the height of the display by some amount, messing up the aspect ratio as well.
Here is a built version of the sample set to 250 x 250, which on my Windows 7 computer draws like this:
www.draconiansimulations.com/of/ToggleFullScreenTest.zip
I assume if you run it, it will show like yours does on your computer, confirming it’s Windows 10’s way of showing the program that is the issue.
In which case, the question is how to get OF to respond and get Windows 10 to behave itself. I have so far avoided programming for Windows 10, so I’m not familiar with this issue or what can be done about it.
Edit: Googling a bit for “windows 10 stretching display”, I see there are quite a few pages going on about display stretching issues, but they’re all pretty primitively written so I haven’t yet found one that makes it clear whether it’s the same thing or some other issue.
Yup, the same origin offset and pixel stretch issue appears when I run that exe:
Fairly fundamental this problem, it leaves me kind of stuck right now.
Yes, that is an awful problem, I agree.
The worst part is the origin being under the title bar, and the stretching.
It’s also peculiar to me that the screenshot you sent from running my version does have a 250 x 250 apparent window under the title bar, but the screenshot you sent of yours was 246 x 246.
What do ofGetHeight() and ofGetWidth() return at run-time when the request was for ofSetupOpenGL(250,250,OF_WINDOW) ?
This seems like we may need an expert to help… @arturo ?
Curiouser and curiouser…
When ofSetupOpenGL(250,250,OF_WINDOW), then ofGetWidth() getHeight() does indeed return 250,250
When other dims or OF_FULLSCREEN, and then setting window size at toggle to be 250,250, the dims come in at 246,246
In both cases the origin and pixel stretch bugs are consistent.
Expert opinions would be very welcome! At least for now I know I am not going mad, though it feels like it…
Not sure what’s going on, sounds like a bug in the custom code we use to switch between full screen and not full screen, perhaps something that only happens on latest versions of windows. Can you open a bug in github?
Ok I’ve raised an issue on GitHub.
In the meantime, I have been mashing my face against my keyboard in an despairing attempt to find a solution.
I’ve discovered (don’t ask how, it is a lost 5 hours of my life) that if I use the ofxMSAOpenCl addon by @memo (i.e. link it all in) and then include the following two lines:
#include “MSAOpenCL.h"
msa::OpenCLBufferManagedT<float>whatever;
then hey presto, neither the origin offset nor the pixel stretch is an issue any more in windows mode. waaa!
This isn’t really a practical solution, as it is an entire (quite complex) addon dependency for no real reason. But, I assume that the declaration must be doing something of which I am unaware. So is it a hint as to what might be a fix??
How could I chase this up further? /or are there any other possible routes to a solution that I could try and hunt down?
hopeful again,
S
hmmm, I wonder if it has to do with your graphics card and maybe when add that line it uses a different card (for example on mac, I have an intel and an ATI graphics card).
You can try the example in
examples/gl/glinfo
to get more info about your card – for example, this is what mine says:
(you can also hit space for more info). might be interesting to see what it says when you do and don’t have that line which seems to fix things.
