Skip to content

Ability to cap the canvas size#3641

Merged
ngokevin merged 13 commits intoaframevr:masterfrom
benjaminleonard:max-canvas-size
Jul 3, 2018
Merged

Ability to cap the canvas size#3641
ngokevin merged 13 commits intoaframevr:masterfrom
benjaminleonard:max-canvas-size

Conversation

@benjaminleonard
Copy link
Contributor

Description:
Adding an attribute to the scene component which allows you to set a maximum height/width.
Currently, you get some big frame drops on high-density screens in a full width window – especially on iMacs & Macbooks with retina screens and slightly less powerful GPUs.

Was just a first stab.
Would it be more useful with a separate width and height attribute?
Tried this rather than a pixel ratio attribute, as you can make the most of the high-density screen at smaller sizes.

@ngokevin
Copy link
Member

Nice. I wanted this because, yeah, fullscreen on Macbook is a drain.

You don't have to build the dist for PRs, you can remove that.

Perhaps renderer="maxCanvasWidth: 1280; maxCanvasHeight: 720"? And I would make it so that if you enter VR, the height and width are ignored?

– Can now set both max height and max width independently
@benjaminleonard
Copy link
Contributor Author

benjaminleonard commented Jun 14, 2018

Great!

I've implemented the two separate attributes, and added them to the renderer schema to stop the warning. Though the default doesn't do anything.

Size caps are ignored in VR mode.

I'll update the documentation also, if that's all okay?

EDIT: Will figure out what's going wrong with the test failing

Copy link
Member

@ngokevin ngokevin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some nit comments. Thanks!

}

function getMaxSize (max, isVR) {
var size = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

define vars-on-top and initialize where needed.

var aspectRatio;
var size;

};
}

function getMaxSize (max, isVR) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call all these variables like definedMaxSize or maxSize.

};
}

function getMaxSize (max, isVR) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you document this function and what isVR will do?

* @param {boolean} embedded - Is the scene embedded?
*/
function getCanvasSize (canvasEl, embedded) {
function getCanvasSize (canvasEl, embedded, max, isVR) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think better order is canvasEl, maxSize, isVR, isEmbedded of importance

rendererConfig.antialias = rendererAttr.antialias === 'true';
}

this.maxSize = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.maxCanvasSize

physicallyCorrectLights: true;"></a-scene>
physicallyCorrectLights: true;
maxCanvasWidth: 1920;
maxCanvasHeight: 1920;"></a-scene>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1080 would be better default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do – but I suppose in most instances you'd be best having them the same value thereby capping for both landscape and portrait aspect ratios

module.exports.Component = register('renderer', {
schema: {
antialias: {default: 'auto', oneOf: ['true', 'false', 'auto']},
maxCanvasWidth: {default: -1},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1920 x 1080 might be a reasonable default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the default be uncapped?

Copy link
Member

@ngokevin ngokevin Jun 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be good to limit as default to 1920x1080 because higher resolutions are overkill. It would be nice if all A-Frame apps are capped because so many people have Retina screens. People can configure it uncapped if they want. For example, ShaderToy caps to a very small resolution.

VR mode is the more important part, I think it's okay to cap what is essentially the preview. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right, it's probably the sanest default – as anything but the simplest scene starts dropping frames on my iMac at full screen.

Though if we set to 1920x1080 – we're automatically constraining portrait devices to a smaller size, so perhaps 1920 x 1920 is better.

If people want to implement different constraints for mobile/tablets, they can do it manually through a custom component.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I added the defaults here, since it avoids the warning for an undefined attribute – but the default value doesn't have an effect, hence this line:

width: rendererAttr.maxCanvasWidth ? parseInt(rendererAttr.maxCanvasWidth) : -1

Is that a problem?

height: window.innerHeight
};

if (!max || isVR || (max.width === -1 && max.height === -1)) return size;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Braces around if statement

> **NOTE:** When glTF models contain lights, use the physically-correct lighting mode to match
> the results in the original modeling tool.

### maxCanvasWidth / maxCanvasHeight
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think can be explained in the attributes table

@ngokevin
Copy link
Member

I played around. I am not sure setSize helps with Retina. The size is already reported as 1440x900 and pixel ratio is 2. Setting pixel ratio to 1 seems like what you'd want to do for Retina?

@benjaminleonard
Copy link
Contributor Author

Ahh, of course.

Let's say your screen was 1920x1080 at pixel ratio of 3 – and the cap is set to 2560 x 2560. If the pixel ratio was then set to 1 but a size larger than the screen, would it cause any problems?

@ngokevin
Copy link
Member

Don't know what that means, size larger than the screen. It varies between screens. My MacBook has a pixel ratio of 2, and it's OS-configured too, my Windows is at 1.25. Rather than maxSize, we should allow configuration of renderer.setPixelRatio(maxPixelRatio)? Also don't know how that plays with the VR renderer.

– Rounding the short side to avoid a decimal size
– Taking into account pixel ratio in sizing and comparison
@benjaminleonard
Copy link
Contributor Author

Agreed that would be much simpler – but maybe there's value in the max size, since it means you can make the most of the pixel ratio at smaller window sizes where it wouldn't be a frame rate issue?
Perhaps we could add an option for pixel ratio also?

I've just pushed a change that should hopefully fix the sizing on retina screens.

@ngokevin ngokevin merged commit 9db81fa into aframevr:master Jul 3, 2018
@ngokevin
Copy link
Member

ngokevin commented Jul 3, 2018

Thanks! Let's see how it goes.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants