It seems that font styles in the default text format
are ignored when dealing with an HTML field.
This patch revisits the fix from feacbdc1 (#13615),
which assumed that `<font>` resets font style.
That does not seem to be the case, but rather the bug
was caused by the invalid default text format,
which forced the text to be bold, due to the bold
variant of the font being linked to the text field.
This patch reverts 2f84d468 (#1201), which assumed that
the default color for a text span has 100% alpha.
The test added here contradicts it and it seems that
the default color is in fact rgba(0,0,0,0).
Testing the original SWF suggests that the underlying problem
has been fixed since that time.
I've switched back to the original code for creating
the bitmap/bitmapdata, rather than relying on custom
initialization logic that we only used in loader.
To make sure that the Bitmap/BitmapData are only exposed
to ActionScript at the correct time, I've added a new flag
to control when 'LoaderInfo.content' becomes non-null
When ActionScript uses a ByteArray/Vector.<Number> as a shader input
or target, we create a temporary Rgba32Float texture, and copy the
input float32 bytes to/from the texture.
Unfortunately, wgpu doesn't seem to support an Rgb32Float (3-channel)
texture. When the shader uses 3 channels, we use a Rgba32Float
(4-channel) texture, and manually insert/remove padding for the
alpha channels. This isn't very efficient, but it's the simplest
solution.
The temporary textures themselves aren't cached anywhere - if this
becomes a performance issue, we could look into using some of our
existing wgpu texture/buffer pooling code.
This opens a searchable list (similar to what we have for display
objects), which shows a tree of Domains and their associated classes.
Currently, clicking on the domain/class buttons doesn't do anything.
In a follow-up, I'm planning to add additional windows to display
information about a class.
Some obfuscated SWFs may have invalid strings in their constant
pool - trying to immediately parse them as a utf-8 String throws
away information. Instead, we now store a `Vec<u8>`, which we
then use to construct an `AvmString` (or with `String::from_utf8_lossy`
for debug printing).
The handling of images in Loader.loaderBytes is similar to
the handling of SWFs - some of the data is exposed immediately
following the 'Loader.loadBytes' call, but the DisplayObject isn't
loaded until later.
Kamil Jarosz