Flash Bitmap Shift Bug - 14 Feb 2005

Ok so there seem to be a lot of different ways to fix this bug. However, methods that worked well in previous versions of Flash can aggravate the problem in MX 2004. As Flash v6 is still more common than v7 in commercial projects (at the time of writing), any work-around for this bug should work for both versions without too much effort. I also think it's important that the work-around should work in both high and low quality modes as reusable components should still work in projects which require the extra speed provided by the low quality (aliased) rendering.

For those of you that aren't familiar with the Flash bitmap bug, it causes bitmaps inside Flash movies to distort and shift. Basically what happens it the first row and column of pixels in any bitmap get doubled up, and the bottom col and right row get clipped. Although in some cases it can affect pixels inside the bitmap too. It is often referred to as wrapping.

In researching possible work-arounds I've ignored any solutions which involve setting the _alpha, _xscale or _yscale values to less than 99.9% as this will definitely impact on the movie performance (And yes, covering the entire movie with a transparent .PNG might work but it is probably the worst thing you can do from a performance point of view).

The available solutions I've examined come from using a combination of:

About the tests

I've set up four flash movies (built in MX 2004 Pro/Win XP) to demonstrate the two most common scale modes ("noScale" and "allowScale") across both Flash 6 and 7 respectively. Apart from that each of the four movies are identical. They contain a grid (made of simple vector lines) and 6 bitmaps (all imported as .GIF and exported a lossless). By the way, you could say there's a bug with way flash renders vectors too - to get the grid to stay still in all quality modes I had to set the _x, _y values for each line to the nearest integer value and then add 0.4.

screen grab
This is a screen grab of the movie from inside the authoring environment. This is more or less what it should look like once published. The bitmaps are the white boxes with the cross through them. Note the single pixel black border around the edge of the bitmap ( example bitmap ) against the grid, you'll see they should line up perfectly.

example bitmap at 400%
And here's a close up of the bitmap.

The tests


Download the FLA here

OK so this first test only really demonstrates what we already know. Bitmaps in v.6 should be placed in movieclips and shifted into negative space by positioning the reg point at the bottom-right corner of the bitmap. However this only works effectively with scaling allowed...


Download the FLA here

...As you can see, with scaling turned off, cycling through the quality modes reveals a considerable amount of shifting. For high quality, the best is definitely the bitmap with the reg point bottom-right, but to use the low quality mode you'll have to put it at top-left. Verdict: avoid setting the scale mode to "noScale" when publishing for v.6


Download the FLA here

And on to v.7. As you can see, with scaling allowed nothing works across all the quality settings, and in fact, the problems and solutions mirror the v.6 example above. Use top-left reg points for high or best quality, bottom-right for low. Verdict: Avoid setting the scale mode to "allowScale" when publishing for v.7


Download the FLA here

OK so this time there's no shifting between modes but shifting has occurred in all the negative space bitmaps. Macromedia fixed the bug and broke the workaround (slaps forehead!!!). Verdict: don't use negative space bitmaps in v.7, bitmaps wrapped in normal (top-left) reg point movieclips work best.

Conclusion

One thing was the same in all the tests was, the one px transparent border doesn't really help. It stops some of the ugliness caused by pixel wrapping, but it can't stop the bitmap from being shifted out of position. As for what to do? Well my first choice would be to only publish for v.7, stop using the negative space work-around and never set the scale mode to allowScale. Alternatively, if you have to use v6 do exactly the opposit! But in any case, make sure you know which version you're publishing for before you spend a lot of time coding graphics or laying movieclips out.

There is something I discovered while doing these tests I haven't seen mentioned elsewhere on the web. If you've got an image in your library used by two different movieclips, one with the reg point lop-left, the other bottom-right, they will both be effected in the same way. The bitmap shifting bug effects all instances of any image in the same way no matter how different instances are positioned with in movieclips. I guess this means that flash draws bitmaps into a buffer before composing the whole frame and if it gets it wrong, the error gets replicated.

One other passing thought crossed my mind. There is so much symmetry between the bitmap bugs in v6 and v7, I wouldn't be surprised if somewhere - deep within Macromedia - someone "fixed" the bug by multiplying a something by minus 1.

If you'd like to send me some abuse or comment on this article you can email me here blockage at misuseit.com (no spam thanks, I've already got all viagra ads I can use)

Hope this helps...