Viewport scaling after reaching bottom 40 pixels of screen... systemChrome=none, transparent=true

[Ten90Studios]

Tweening the viewport down to the bottom of the screen (i have a fullscreen image to show scaling): TweenMax.to(starlingInstance.viewPort, 5, {y:stage.stageHeight - 20});

initialWindow content in descriptor.xml file:

<initialWindow>
        <content>Desktop.swf</content>
        <title>Desktop</title>
        <systemChrome>none</systemChrome>
        <transparent>true</transparent>
        <visible>true</visible>
        <minimizable>true</minimizable>
        <maximizable>true</maximizable>
        <resizable>false</resizable>
        <aspectRatio>landscape</aspectRatio>
        <autoOrients>false</autoOrients>
        <fullScreen>false</fullScreen>
        <renderMode>direct</renderMode>
        <depthAndStencil>true</depthAndStencil>
    </initialWindow>

When the viewport passes the stageHeight-40 pixel coordinate the content starts to scale down in a strange manner

[PrimaryFeather]

Sorry for the late reply!

Hm, what exactly do you mean by "strange manner"? Could you create a screenshot of this behavior?

I'd also love to know why you would want to animate the viewPort in such a way! Typically, the viewPort stays fixed except for device rotations. Animating it requires the context to be reconfigured in each frame; I don't know how well / fast that works on different devices.

[Ten90Studios]

Sorry, I should have clarified.

I have only tested this on Windows. It is a desktop AIR application that I recently upgraded from Starling 1.8 to 2.2 (really great job there, it cut CPU usage significantly) and started seeing this behavior.

The reason for tweening the viewport has to do with the lack of Stage3D transparency. Luckily, the functionality I need only requires rectangular transparent space. So, I am tweening the Starling viewport to reveal the transparent area underneath. When the viewport reaches the final ~40 pixels of the tween, the viewport seems to be decreasing scaleY or something to that effect.

The first screenshot is the top portion of a 1280x720 starling image that fills the viewport. The second is the same top portion of the viewport, but with the viewport sitting below the window height - 40 pixel threshold.

viewport at 0, 0 viewport at 0, 1270

A workaround is drawing the starling stage to bitmapdata and adding that to the native stage, hiding stage3D, and proceeding as usual. But it worked in Starling 1.8 so I thought it could possibly be a bug.

[PrimaryFeather]

Ah, okay! Thanks a lot for the additional information!

What you could be seeing is the following: Stage3D has a minimum back buffer size of 32x32 pixels. In Starling 1.x, I didn't enforce this: if you set a smaller viewPort, it depended on the platform/device what would be happening. Worst case: the application crashed with an error.

That's why in Starling 2.x, I'm now making sure that the viewPort never becomes smaller than 32 pixels (both vertically and horizontally). You can still set it to such a value, but it will be ignored.

Could this be the actual issue? Do your problems start at 32 pixels height?

[Ten90Studios]

32 pixels was indeed the threshold. So, I have implemented the native bitmap solution as a workaround. stage.drawToBitmapData() made it very easy.

Thanks!

[PrimaryFeather]

I'm happy to hear that you found a practicable workaround! :smile: