[HTML5 - WebGL] New Openfl/Lime problems with BitmapData


#1

Hi,
I have just given the new libs (Lime 7.1.1 + Openfl 8.6.1-8.6.2) a try, and I noticed several problem appearantly related to BitmapData creation: it looks like the result of “draw” operation doesn’t give an immediate result, causing empty data, that is usable after 1+ frames, as if the operations were delayed… but this doesn’t happen always.

I noticed a clear improvement in the Away3D performances (even if I noticed a… worse antialiasing?), but for now I have to go back to the old libs (Lime 6.2.0, Openfl 7.1.2).


#2

Does it help if you use -Dopenfl-always-render?


#3

No… and I don’t think this is the problem, otherwise I would have different, minor problems: in my case rendering is done, but some Bitmaps (created drawing on a BitmapData) don’t show up, and in a specific case getColorBoundsRect returns a null (0, 0, 0, 0) rectangle, as if the BitmapData was empty. It looks like there is a (random?) delay between the draw call and the effective insertion of the pixels in the BitmapData container, even if it should be impossible because it is done synchronously. Maybe some missing update of the new contents/dirty flags?
As always test code would help, but… “it’s complicated”.


#4

The new libs, Openfl 8.6.4 and Lime 7.1.1 fix some problems, but I still have issues with getColorBoundsRect, it returns an empty Rect.


!!! UPDATE !!!
The item on which I am executing the getColorBoundsRect is contained in a Sprite with alpha = 0!
This means that the problem is (seems to be) caused by the container, the item inherits its properties and fails in searching for opaque pixels because pixels are not visible!
If I set alpha = 0.01 it works.


#5

Does that alpha value on the container make a difference on the Flash target?

Could you share some simple psuedo-code of what you’re trying to do (and isn’t working) if the Flash target does work differently? Thank you!


#6

I can’t compile to Flash, but I think that Flash should work as Openfl worked before: an item should work independently from its container, the container properties shouldn’t influence the inner items behaviour.

In my case I have a BitmapData that appears to be empty (to getColorBoundsRect) because the container alpha is 0.
I will try to add pseudo code as soon as possible.


#7

Hmm, I don’t think the alpha of a container would affect this:

Unless you called disposeImage on the BitmapData? …though that would make it not return after it was rendered, so the reverse, if I understand correctly


#8

I’ll try to extract a decent piece of pseudo-code.


#9

Here a piece of code to illustrate what I do:

box = new Sprite();

boxTF = new AdvTextField();
boxTF.x = maxTextWidth / 2;
box.addChild(boxTF);
box.alpha = 0;

boxTF.text = "hello world";

Actuate.tween(box, 0.4, {alpha: 1});

—> the application hangs in a loop.

AdvTextField is a class that improves textfields usage, by handling them like bitmaps, allowing pixel-perfect alignment and horizontal/vertical scaling. Scaling is what is causing the problem with the new Lime/Openfl libraries, because when I update the textfield text the textfield content is rasterized to an opaque BitmapData, and cropped by .getColorBoundsRect, to obtain the effective text bounds.

The steps are as follows:

  • I update the TextField
  • I get the TextField bounds by .getBounds, and they are consistent, width and height are correct
  • I use the obtained bounds to instance the BitmapData
  • I draw the TextField to the BitmapData
  • I get the rasterized TextField bounds by .getColorBoundsRect, and they are void

If I set box.alpha to 0.01 the Rect returned by .getColorBoundsRect is correct.

It behaves like I am setting alpha to the TextField I am drawing to the BitmapData, while I am setting it to “box”, that contains the AdvTextField instance, that contains the TextField that I draw to the BitmapData.


#10

What size is the rasterized BitmapData? Is it possible that it’s sized 0x0?

Perhaps after creating the BitmapData, nothing from the TextField is rendered to the BitmapData? Perhaps you could force the internal TextField to have an alpha of 1 before you rasterize it, so it is always visible, if that’s the issue?


#11

getBounds detects the correct TextField size, so I suppose the generated BitmapData is the same size, but I will check this, and try to force the alpha.


#12

Even if I force the TextField (and .parent too) to alpha = 1, visible = true, cacheAsBitmap = false… whatever, it continues to be rendered as invisible, even if its size is > 0x0.
I also disabled autoVisible in the tween.

If I avoid to set the container alpha to 0 the TF is effectively drawn to BitmapData and eventually cropped.