wonderfl - build flash online

BitmapData#draw() bug?

is this bug? anyone can explain why result bitmap looks like this?

codeonwort codeonwort

add to favorites

Embed

Code Fullscreen

Talk

This code draws a bitmap onto itself. Flash must be trying to do it in place.

  • by wh0
  • at 2012/03/24 08:33:08

i think line 33 should works like line 35~36 If bd.draw(bd) call makes a temporary clone of itself.

I don't see anywhere in the documentation that it promises to make a clone. Note that using draw() to render a BitmapData into a BitmapData isn't used that often: you're more likely to use copyPixels() (which does say you can use the target as the source).

One fix: replace the first parameter of the problem call with bd.clone().

copyPixels() only support pixel to pixel transfer. Using copyPixels() I cannot use matrices to transform the source bitmap data. and If we use bd.clone() does it disposed automatically even though I do not call dispose() of that clone?

I would think once cloned and used it will stay around unreferenced to be garbage collected. So you don't want to be doing it that often. If you need to do it a lot create a buffer which is kept around, copyPixels() the image into it (maybe faster than cloning too), then use that as the 1st parameter for draw.

let me make things clear. I created bitmap filters for real time usage. and I found that when I call bd.draw(bd, matrix) result looks odd. So I made a temporary buffer, let's say temp, and replaced the line with temp.draw(bd, mat); (there are further operations for filtering. that;s not the matter) What I am wondering is why the result of drawing bitmap data to itself looks like above flash.

Like wh0 said, flash is reading and writing to the same block of memory, without a matrix the resulting value of a pixel depends only on it's initial value, but with a matrix the output pixel at say (10, 10) may depend on some other pixel, say (5,5). Now, if draw() happens to update (5,5) before it gets around to (10,10) the output won't be what you expect.

  • by yonatan
  • at 2012/03/29 11:31:37

another example: http://wonderfl.net/c/be8I

  • by yonatan
  • at 2012/03/29 11:34:29

if you're very very bored you can probably come up with a program to determine the order at which flash reads/writes pixels based on the distortion of the output :)

  • by yonatan
  • at 2012/03/29 11:39:35

aha what wh0 said is it. problem & doubt solved, thanks to all of you!

there were times when applyFilter used to do this, and codes like http://wonderfl.net/c/vCci could work in just one applyFilter call. now it makes temp bitmap copy

  • by makc3d
  • at 2012/03/29 21:56:02

Tags

sectKeywords

Forked

ページの先頭へ戻る