Objects Hidden Using ScrollRect Blocking/Triggering Input Events

Question

The project is written in as3, packaged using AIR 28.0, and run on an Android 7 device (when run on a windows desktop environment it works fine).

Objects that are hidden from view by a scrollRect are still receiving mouse events on my Android 7 (S7), but not when I run the same exact application in a desktop environment.

Is this an Android or AIR bug? Or am I doing something wrong?

Example:

EDIT: (Original code example was incomplete see edit below)
var button:Sprite = new Sprite();
button.graphics.beginFill(0x00FF11, 1);
button.graphics.drawRect(0, 0, 50, 50);
button.graphics.endFill();
addChild(button);

button.addEventListener(MouseEvent.CLICK, buttonClick);

var outer:Sprite = new Sprite();
var square:Sprite = new Sprite();
outer.cacheAsBitmap = true;
outer.addChild(square);
var rect:Rectangle = new Rectangle(0, 0, 50, 50);
outer.scrollRect = rect;
addChild(outer);
outer.y = 50;

square.graphics.lineStyle();
square.graphics.beginFill(0x000000, 1);
square.graphics.drawRect(0, 0, 100, 100);
square.graphics.endFill();

square.addEventListener(MouseEvent.MOUSE_DOWN, squareDown);
square.y = -50;

In this example the rectangle drawn in the inner object is only visible within the outer.scrollRect (so 50x50 instead of 100x100) and the button object is visible above it. When a click event happens over the visible button however the innerClick event will fire, not the buttonClick event.

It seems that the invisible portion of the inner container, hidden by the applied scrollRect, is only hidden visually and still blocks input events.

The application is being compiled and installed through my IDE (Flash Builder). I have tried different versions of my IDE and AIR SDK, with the same results.

Any help would be greatly appreciated.

EDIT:

I found instances where scrollRect worked properly so did further testing to narrow down the bug.

Removing the line:

outer.cacheAsBitmap = true;

... fixed the issue. Applying cacheAsBitmap to the square object itself also still worked fine.

For some reason applying cacheAsBitmap to the object with the scrollRect causes this bug, but applying cacheAsBitmap to objects that are children further down the line works as it should.

I'm not experienced enough to know the performance implications or why it is suggested to add cacheAsBitmap to the object with the scrollRect. Maybe someone else can inform.

Answer 1

The scrollRect property is probably the most performance-wise way (with the regular Flash content) to clip some content with a rectangular mask.

The cacheAsBitmap property allows to relieve Flash Player of need to render the content of the object unless something changes inside the object.

To put it simply. Imagine a page of richly illustrated fairy-tale book: an overcomplicated vector picture with lots of details, some texts with fancy fonts, etc. You put it on stage, Flash Player needs to render all of it: vector fills and strokes, fancy fonts. Then, you don't change anything over the course of several frames, Flash Player does not need to render anything, it is good. Then you shift this page 1px to the right and - guess what - Flash Player needs to render the whole thing again.

Any change under that page, or over that page, or to that page - anything withing that page's bounding box - will make FP to render the page's whole content again - which would take a pretty heavy toll on performance.

Using cacheAsBitmap allows FP to render it only once, so only internal changes to that page will make FP to render it again, anything else will make FP just use the cached version which is faster than rendering it over and over again. Which is, I agree, might be a solution to mobile devices for they are slow and CPU-lacking.

Hence if your app has elements that:

• contain complicated vector shapes and text
• are static or change quite rarely
• are not overly large

then you can cache them with cacheAsBitmap = true to gain some performance at the expense of RAM.

However.

If you are building a store-grade product, not just a school project or something for personal amusement, I advise you to look into Gamua Starling because you'll never get your app any close to running smoothly with regular Flash content. As soon as you need to redraw the whole screen the FPS will drop to the bottom of the sea, because Flash is CPU-hungry while mobile devices are CPU-lacking. Starling, on the other hand, utilizes Stage3D and device's GPU resources so you can have something overly rich and animated running at 60 FPS with no sweat.