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).
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”.
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.
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.
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.
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?
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.