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

Framebuffer stretched in landscape orientation #549

Closed
notlion opened this Issue Oct 27, 2014 · 5 comments

Comments

Projects
None yet
3 participants
@notlion
Contributor

notlion commented Oct 27, 2014

Previously posted to the forum.

It looks like the AppImplCocoaTouchRendererGl framebuffer is being allocated for portrait orientation and then stretched to fit when the orientation is switched to landscape. It looks as though backingWidth and backingHeight never change, even when the orientation changes.

An example to show the stretching:

Landscape

stretched

Portrait

non-stretched

Sketch used to produce these images
#include "cinder/app/AppNative.h"
#include "cinder/app/RendererGl.h"
#include "cinder/gl/gl.h"

using namespace ci;
using namespace ci::app;
using namespace std;

class TestFramebufferApp : public AppNative {
public:
  void draw() override;
};

void TestFramebufferApp::draw() {
  gl::clear(Color(0, 0, 0));
  gl::color(1, 0, 0);

  auto c = getWindowCenter();
  gl::drawLine(c + vec2(100), c - vec2(100));
  gl::drawLine(c + vec2(100, -100), c + vec2(-100, 100));
}

CINDER_APP_NATIVE(TestFramebufferApp,
  RendererGl(RendererGl::Options().antiAliasing(RendererGl::AA_NONE)))
@notlion

This comment has been minimized.

Show comment
Hide comment
@notlion

notlion Oct 27, 2014

Contributor

It looks like moving the renderbufferStorage call before the width / height are queried fixes things. I'm not sure if this is the correct solution, though...

// Allocate color buffer backing based on the current layer size
glBindRenderbuffer( GL_RENDERBUFFER, mViewRenderbuffer );

[mContext renderbufferStorage:GL_RENDERBUFFER fromDrawable:(CAEAGLLayer*)mCinderView.layer];

GLint backingWidth, backingHeight;
glGetRenderbufferParameteriv( GL_RENDERBUFFER, GL_RENDERBUFFER_WIDTH, &backingWidth );
glGetRenderbufferParameteriv( GL_RENDERBUFFER, GL_RENDERBUFFER_HEIGHT, &backingHeight );
Contributor

notlion commented Oct 27, 2014

It looks like moving the renderbufferStorage call before the width / height are queried fixes things. I'm not sure if this is the correct solution, though...

// Allocate color buffer backing based on the current layer size
glBindRenderbuffer( GL_RENDERBUFFER, mViewRenderbuffer );

[mContext renderbufferStorage:GL_RENDERBUFFER fromDrawable:(CAEAGLLayer*)mCinderView.layer];

GLint backingWidth, backingHeight;
glGetRenderbufferParameteriv( GL_RENDERBUFFER, GL_RENDERBUFFER_WIDTH, &backingWidth );
glGetRenderbufferParameteriv( GL_RENDERBUFFER, GL_RENDERBUFFER_HEIGHT, &backingHeight );
@andrewfb

This comment has been minimized.

Show comment
Hide comment
@andrewfb

andrewfb Oct 28, 2014

Collaborator

I'm starting to try to replicate this but by default a Cinder iOS app will ignore orientation changes (so in your example above nothing should happen if you rotate the screen from portrait to landscape - it will just stay in portrait). Are you adding a slot for the supportedOrientations() signal or similar?

Collaborator

andrewfb commented Oct 28, 2014

I'm starting to try to replicate this but by default a Cinder iOS app will ignore orientation changes (so in your example above nothing should happen if you rotate the screen from portrait to landscape - it will just stay in portrait). Are you adding a slot for the supportedOrientations() signal or similar?

@notlion

This comment has been minimized.

Show comment
Hide comment
@notlion

notlion Oct 28, 2014

Contributor

I've tested with InterfaceOrientation::LandscapeAll orientation, yeah. Also, I'm not sure if this is the case with the iPhone, but on iPad the app will start in whatever orientation the device is in when it's opened, regardless of if it's supported or not.

Contributor

notlion commented Oct 28, 2014

I've tested with InterfaceOrientation::LandscapeAll orientation, yeah. Also, I'm not sure if this is the case with the iPhone, but on iPad the app will start in whatever orientation the device is in when it's opened, regardless of if it's supported or not.

@notlion

This comment has been minimized.

Show comment
Hide comment
@notlion

notlion Oct 28, 2014

Contributor

Just to be clear; I added this setup function to the TestFramebufferApp and still see the same behavior:

void TestFramebufferApp::setup() {
  getSignalSupportedOrientations().connect([] {
    return InterfaceOrientation::LandscapeAll | InterfaceOrientation::PortraitAll;
  });
}

Seems like renderBufferStorage:fromDrawable needs to be called in order for the renderbuffer size to actually change?

Contributor

notlion commented Oct 28, 2014

Just to be clear; I added this setup function to the TestFramebufferApp and still see the same behavior:

void TestFramebufferApp::setup() {
  getSignalSupportedOrientations().connect([] {
    return InterfaceOrientation::LandscapeAll | InterfaceOrientation::PortraitAll;
  });
}

Seems like renderBufferStorage:fromDrawable needs to be called in order for the renderbuffer size to actually change?

@richardeakin

This comment has been minimized.

Show comment
Hide comment
@richardeakin

richardeakin Oct 28, 2014

Collaborator

I've tested with InterfaceOrientation::LandscapeAll orientation, yeah. Also, I'm not sure if this is the case with the iPhone, but on iPad the app will start in whatever orientation the device is in when it's opened, regardless of if it's supported or not.

Ha, thought no one noticed. Yea.. this is a bug and I thought of a fix a while back, but its a bit ornery so didn't get around to it. I think it involved parsing the App's info.plist file for possible orientations..

Collaborator

richardeakin commented Oct 28, 2014

I've tested with InterfaceOrientation::LandscapeAll orientation, yeah. Also, I'm not sure if this is the case with the iPhone, but on iPad the app will start in whatever orientation the device is in when it's opened, regardless of if it's supported or not.

Ha, thought no one noticed. Yea.. this is a bug and I thought of a fix a while back, but its a bit ornery so didn't get around to it. I think it involved parsing the App's info.plist file for possible orientations..

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