This doesn't work right yet because the resulting width doesn't apply correctly to the field. This is because `EditText`'s `_width` and `_height` change it's intrinsic bounds rather than it's X and Y scale (like it would with a button or a movie clip).
These tests depend on the particulars of our default device font, Noto Sans. If this test proves to be fragile we may need to create a testing font with a locked width and kerning table...
This prevents a bounds-check panic when we inevitably try to slice an array like `[300..2]` or something like that.
We also skip rendering the space that we're turning into a newline to avoid it popping up on the next line by accident.
`max_length` isn't a geometrical width, despite the fact that the type system didn't prevent me from making erroneous conversions. It's actually just a text length limit, which we won't be dealing with for some time.
When first instantiated, we use the static bounds; however, further relayouts grab `local_bounds` and calculate a width from that. `EditText` works almost identically to any other display object, with the exception that device fonts do not render if the transform is not an axis-aligned bounding box (and it doesn't respect scale). We don't have to worry about that for now.
This is surprisingly difficult because of how Flash handles these properties: they are cached at the start of a new line (explicit or flown) and then used for all spans that intersect with that line. Ergo, `LayoutContext` needs to keep track of all the boxes we generate within the line and the span that ultimately is going to provide margins for it.
And yet, at the same time, we also have to precalculate the effects of these margins when flowing text so that we know how much space we have to play with. This needs to be calculated the same at the start of the line as it is at the end. This is why `LayoutContext` is a separate type: it handles all the state tracking and crap that has to be done when splitting text into spans, paragraphs, and lines all at the same time.
Fortunately, this design will make it easier to implement other features like text alignment where we couldn't even begin to calculate everything in one pass.
This involves a new struct called a `FontDescriptor` which is generated whenever a font is registered and used to index the font in the library. When a font is requested, it goes through the descriptor system to get found.
"Mixing" is defined as `Option.or`ing all the properties in the new text format with the old one. Not specifying a text format in the new default will result in the field retaining it's old properties.
This yields nodes as `Step`s. This allows keeping track of the structure of the tree as you walk through descendents, as each element will be yielded twice: both as a `Step::In` *and* as a `Step::Out`. Non-element nodes will be yielded once as a `Step::Around`.
I'm adding `walk` iteration specifically to avoid having to write certain methods recursively. Existing recursive callers of `children` should probably be updated to `walk` the tree and maintain a separate `Vec` stack.
This also necessitated the addition of code to:
* Ensure span breaks exist at both sides of the text boundary, without creating degenerate (length-0) spans
* Consolidate spans with matching text formats
* Shorten or lengthen the total list of text spans to match the backing string
* Ensure at least one text span exists at all times
This still has some minor to-dos: for example, it relies on the default `TextSpan` formatting, which probably should be replaced with actually accepting or storing a default format to be used when constructing new text spans.
Despite having HTML and CSS rendering capabilities, the Flash text field actually does not use HTML as it's internal representation. Instead, the text-span format implied by `getTextFormat` and `setTextFormat` is used to drive layout. You can see this by watching what happens to `htmlText`, *especially* when you add and remove stylesheets.
The `LayoutBox` machinery will be adapted to consume text spans in a future commit. This would make the entire rendering pipeline: HTML/CSS -> Text Spans -> Layout Boxes -> Render commands.
This makes the implementation of rectangle union (`Add`/`AddAssign`) far easier as we just compute the min and max of the offset and extent coordinates. It also makes the conversion into and from `swf::Rectangle` easier as it's now effectively a generic version of that datatype.
On the other hand, `width`, `height`, and `size` now have to be calculated, and require `T` to be self-`Sub`. I'm not sure if this is that much of a problem or not.
We're reusing the XML machinery to handle HTML - this is probably not 100% correct, but writing a new HTML parser to cover just `EditText` will be rather complicated.
If a class is registered to a clip that is placed on the timeline
during a goto, that constructor should run after the frame is
completely constructed. In order to tell whether to run the
constructor immediately, add a parameter to `post_instantiation`
to indicate if the clip is instantiated from the AVM or via a
standard timeline seek.
There was a one-frame-off flicker when a button changed states.
Now children will tick a frame so that they are properly created
immediately when the parent button changes state.
Previously a MovieClip's clip action would have a set of events
that would trigger it. Now we flatten these out into a single
event per action, because this is by far the common case. If an
action does happen to have >1 event, it will be duplicated for each.
Don't call `render` from `Player::tick`; instead, require the
frontends to explicitly call `render` when they wish to redraw.
The frontend can query `Player::needs_render` to see if the stage
is dirty and needs a redraw. Update desktop and web to use this
new method.
This fits better with the newer winit event loop model, which
requires explicitly calling `request_redraw`, and should avoid
spurious renders.
A previous version of this PR (whose history has been scrubbed, but go check 918d88abe68b7467a4194738b95e5bf3e9b5bb72 if you're curious) implemented a new `TObject` property which basically every line of code that dealt with object construction had to populate. It was terrible.
This is accomplished via two new `TObject` methods: `has_own_virtual` and `call_setter`. If an object does not contain it's own version of a property, it will first crawl the prototype chain to see if there is an overwritable virtual. If so, it will invoke that prototype's setter.
A bit of borrow finangling was required to do this; `super` now no longer caches it's proto and constr values and instead dynamically constructs them. This also means it can't be downcasted to `Executable` anymore.
With this commit, virtual setters and super-setters now work correctly.
A base prototype is only applicable in cases where a method is being called as a property on an object. Bare function calls, `apply`/`call` calls, and so on do not generate a base prototype.
We also add a convenience method, `call_method`, to all objects. This method automatically calculates the correct base prototype for a method call on an object, which is the only operation that should generate base prototypes.
Revert to the old action queue method of popping off actions in a
loop, as new actions can be queued while iterating. Store proto
changes in a separate queue to maintain the high priority behavior.
Change `ActionGetTime` (`getTimer`) to use a new backend method.
This allows it to return updated times if it is called multiple
times in a single frame. This fixes hangs caused by games that use
busy-loop "frame limiter" code.
`PropertyMap` wraps over `IndexMap` to handle object properties in
AVM1. All insert/remove/get methods require and `swf_version`
parameter, and the `PropertyMap` will take care of handling case
senstivity and maintaing iteration order based on the SWF version.
First implementation of Button object. Hook up to the button
display object and run onRelease etc. methods as appropriate.
Pull out common display object methods into globals::display_object.
This conversion allows negative octal values, but not negative
hex values, and ignores only leading ASCII whitespace. A test
for this behavior is included.
Specifically fall back to the device font when the UseOutlines
flag is not set in DefineEditText (SWF19 p.172). Fixes#451.
Note that since we only use a single font for "device" rendering,
this may sometimes be a different font than is specified in the
Flash IDE.
It doesn't feel like Flash without having the hand cursor display
when hovering over buttons. First pass at implementing this;
core communicates which mouse cursor to use via
`InputBackend::set_mouse_cursor`.
TODO: Hand cursor only displayed for Button display objects
currently. Movie clips should also display this when they are in
"button mode" (when a button mouse event is set on them in AVM1,
or `buttonMode` property in AVM2).
Implements MovieClip.getBounds, and also reorganized the
DisplayObject AABB methods:
* `self_bounds` calculates the inherent untransfomed bounds of
the object without children. All `DisplayObject`s must implement
this method. For example, `Bitmap` returns the size of bitmap.
Composite objects like `MovieClip` return a null AABB because they
are made up of only children.
* `bounds` calculates the untransformed bounds including children.
* `local_bounds` calculates the bounds relative to the object's
parent.
* `world_bounds` calculates the bounds in global stage space.
* `bounds_with_transform` calculates a tight AABB for the object
with a given transform, and is used to implement the above.
Try to keep style more consistent by using functions for all MC
methods. Previous was a mix of closures and functions (we're still
a little bad with this elsewhere)
This is caused by the fact that `avm.root_object` references the *current* stack frame, not the one we are about to introduce. Ergo, we need to pull the base clip of the *new* stack frame and find it's root.
This particular behavior only crops up in situations where there can be multiple root objects, at least until we implement `_lockroot`.
`_root` is calculated dynamically based on the clip the currently executing function was called in.
Other things that used `context.root` have been changed to either update all layers or just update layer 0, which is the former `context.root`.
Interestingly enough, very little actually has to be done inside the async process for XML. The async process basically just fetches data and fires an event handler when it's done. Everything else is handled via a system builtin, `XML.onData`.
This implementation just returns the size of the current loaded movie. The test is also deliberately written to be loose on timings so that it likely won't see a partially loaded movie. (I don't want it to be a test of load events, so I just wait a few frames, rather than the correct way of waiting for `onLoadComplete`.)
Until we support streaming file loads, we can't faithfully support these properties. Still, it's better to have them, just in case.
This is technically better, but it may make more sense to trigger `ClipEvent::Load` at the start of the next frame instead. Furthermore, I don't know if other forms of load events should trigger on the next frame (or end of the current one) like this.
This also adjusts `MovieClip.unloadMovie` to do just that, instead of removing the clip from the display list. We also have to unload clips when loading new movies into them, since `unloadMovie` desugars to loading `""` as the URL.
Interestingly, this constitutes an implementation of `AsBroadcaster`. It appears Macromedia decided to implement event handling on `MovieClipLoader` in a very similar fashion to `AsBroadcaster`, down to invoking `broadcastMessage` and searching a `_listeners` property for listeners.
*De*implement the free function versions of the above, as well as their `Num` variants, since they don't actually exist as callables. Instead, the ActionScript compiler treats them as preprocessor functions that represent various forms of `ActionGetURL`/`ActionGetURL2`.
This function is part of `Avm1`, rather than a hypothetical `LayerManager`, because we're going to need to eventually construct layers differently for AVM2.
This has some subtle problems: we cannot hold references to garbage-collected data in Futures, so we have to arrange for the AVM itself to forcibly root them for us. Then we get them back when our async code is ready to do something to the AVM.
This allows the formation of `'static` futures that can still interact with a player. Async code will need to upgrade the weak reference in order to be able to interact with the player.
Due to some strangeness with the way Rust implemented unsafe-to-move behavior, boxed futures are implicitly `Unpin`. Which is useless to us.
The reason for this is a little counter-intuitive. Actually, the fact that Rust supports memory pinning at all is a little odd, because the core language explicitly requires all types be movable. To get around this, Pin requires that all !Unpin types be *born pinned*. This is because you can't re-pin an already unpinned value in memory.
Anyway, this necessitates this silly API change.