[F8] [BUG ALERT] BitmapData Transparency in Flash Player 8+

[Q__Hybrid]

I've noticed a glitch in Flash Player 8+ and thought that I would share it in case some of you were unaware.

When you use cacheAsBitmap, transparency within the movieclip it is applied to will render with a slight "ghost" similar to a white fill with an _alpha value of 1. The end result is that the movieclip's bounding box will become noticable at render time.

So far, I have experimented with ways to eliminate this artifact and the only thing I've found that resolves the issue is to set cacheAsBitmap, then apply a mask to the cached bitmap that preserves the transparency of the original movieclip.

renderhjs, I noticed alot of this "ghosting" in your node based pathfinding engine's demo in particular. Vengence MX, your troops demo suffers from it also.

I'm on an older machine which may have hardware that presents this bug as opposed to newer machines. Be that as it may, if you're a purist and want a clean render, look into applying a secondary mask after caching your bitmaps.

[RipX]

Good call...Here's a bug I just found, also using the Bitmap stuff:

import flash.display.BitmapData;
//
var backBufferBmp:BitmapData = new BitmapData(550, 400, false, 0x0000FF00);
var backBuffer:MovieClip = _root.createEmptyMovieClip("backBuffer", this.getNextHighestDepth());
backBuffer.attachBitmap(backBufferBmp, _root.getNextHighestDepth());
//
var frontBufferBmp:BitmapData = new BitmapData(550, 400, false, 0x00FF0000);
var frontBuffer:MovieClip = _root.createEmptyMovieClip("frontBuffer", this.getNextHighestDepth());
frontBuffer.attachBitmap(frontBufferBmp, _root.getNextHighestDepth());
//
function flip() {
	backBuffer.swapDepths(frontBuffer);
}
setInterval(flip, 1);

When I move the mouse over the flash player window, everything grinds to a complete halt :|

WARNING: Anyone with photosensetive epilepsy, this flashes!! Its a test of switching between a front and back buffer!!

RipX

[iopred]

This bug is usually when you're graphics aren't set to 32 bit, it's been around forever, but isn't usually a problem, because only the slower computers run lower than 32bit, and even then, usually can't run most of the games at nice speeds.

To clarify, it's a bug with Bitmap's because 0 transparency pixels are still drawn, it only arises as CacheAsBitmap because the MC now is a square image. If you import a transparent bitmap, you'll get the same thing.

[renderhjs]

renderhjs, I noticed alot of this "ghosting" in your node based pathfinding engine's demo in particular. Vengence MX, your troops demo suffers from it also.

I am absolutely aware of this, in fact I was already aware of it back in Flash 5 days that with lower settings as 24 bit (but I am sure most use anyway 32 bit) those 1 % opacity exists. But that is not something that shocks me as for my engine back then and even now there is now better performance solution that will do (and no vectors are just lame).

On a sidenote (dont know how the situation now is) but with Flash 5 there was also support for Black & White (monochrome) displays. I tested it back then with win 95 / 98 a few times just for fun. But today they kicked the feature out of windows setting your colors to B/W

[Q__Hybrid]

Is there a way to avoid this issue while running in 24-bit color mode?

I've considered using a bitmap with mask values (black and white), then using it to define opaque and transparent regions in a movieclip, but I'm not certain if it would get around this glitch. I'm pretty sure that using one BitmapData to mask another BitmapData would simply result in the same artifact.

As far as I know, the only way to make B/W graphics is to apply ColorMatrixFilter.

[Q__Hybrid]

With regard to the backbuffer script, I have noticed this bug and it is extremely annoying.

What seems to be the case is that Flash uses an interrupt request to watch the mouse, which means any routine that's running during movement of the mouse gets halted just long enough to acquire information from the mouse.

This only seems to be an issue when using setInterval(), or for() loops in onEnterFrame(). This means that if you stray from the built-in timeline functions, Flash apparently has no way of efficiently executing routines while handling mouse events. If your routines are too lengthy, they can also cause the same problem even if they're in an onEnterFrame() handler.

I'm not sure what the solution is for this, pending an evolution in the compiler that allows you to ignore mouse events explicitly, or perhaps switching over to AS3.

[Squize]

The mouse delay is only really noticeable if you're testing at 120fps, or pushing the Flash player to it's limits ( Such as in the above example, by updating two huge bitmaps every ms ).

Squize.

[VENGEANCE MX]

Vengence MX, your troops demo suffers from it also.

Yes, only discovered that my engine had the problem when I tried it out in the IT room of my school a few days ago (turns out one of them has Flash Player 9). It's a Windows bug, always has been. Don't get it on my Macs, under any colour settings (256, Thousands, Millions). Not exclusive to bitmaps either. Got it on all the old Flash games I made before I used bitmaps, whenever I tried to hide stuff by setting its alpha to 0 (again, I said old Flash games ).