| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
This is where the fun begins. :^)
|
|
|
|
|
|
Instead of passing a GlobalObject everywhere, we will simply pass a VM,
from which we can get everything we need: common names, the current
realm, symbols, arguments, the heap, and a few other things.
In some places we already don't actually need a global object and just
do it for consistency - no more `auto& vm = global_object.vm();`!
This will eventually automatically fix the "wrong realm" issue we have
in some places where we (incorrectly) use the global object from the
allocating object, e.g. in call() / construct() implementations. When
only ever a VM is passed around, this issue can't happen :^)
I've decided to split this change into a series of patches that should
keep each commit down do a somewhat manageable size.
|
|
This is a continuation of the previous six commits.
The global object is only needed to return it if the execution context
stack is empty, but that doesn't seem like a useful thing to allow in
the first place - if you're not currently executing JS, and the
execution context stack is empty, there is no this value to retrieve.
|
|
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
|
|
This is a continuation of the previous four commits.
Passing a global object here is largely redundant, we definitely need
the interpreter but can get the VM and (later) current active realm from
there - and also the global object while we still need it, although I'd
like to remove Interpreter::global_object() in the future.
This now matches the bytecode interpreter's execute_impl() functions.
|
|
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
|
|
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
|
|
This is a continuation of the previous commit.
Calling initialize() is the first thing that's done after allocating a
cell on the JS heap - and in the common case of allocating an object,
that's where properties are assigned and intrinsics occasionally
accessed.
Since those are supposed to live on the realm eventually, this is
another step into that direction.
|
|
No functional changes - we can still very easily get to the global
object via `Realm::global_object()`. This is in preparation of moving
the intrinsics to the realm and no longer having to pass a global
object when allocating any object.
In a few (now, and many more in subsequent commits) places we get a
realm using `GlobalObject::associated_realm()`, this is intended to be
temporary. For example, create() functions will later receive the same
treatment and are passed a realm instead of a global object.
|
|
|
|
Like any other regular, non-inheriting web platform prototype, the
prototype's prototype should be Object.prototype, not the global object.
Another reason to get rid of "global object (an object) + prototype
object (also an object)"-style APIs for allocation :^)
|
|
As per the FIXME.
|
|
This also demotes the constant to floats instead of doubles, because we
truncate it to int anyways and don't need the extra accuracy.
|
|
|
|
Previously if `background-size` was 0px in any dimension we would
go into in infinite loop whilst painting.
|
|
The on_segment_change handler introduced in
a00fa793b37550a8b44122192346eeeb1d692bf9 was only getting called by
programmatically setting the segment, not by clicking a button or using
tab navigation.
|
|
This patch makes the handler's behavior closer to what can be expected
from it's name by not handling set_selected_segment if the segment is
already selected.
|
|
This deadlock would incorrectly change the queue from almost empty to
full on dequeue because someone else could empty the queue after we had
checked its non-emptyness. The test would deadlock on this, which
doesn't happen anymore.
|
|
These just resolve to an extra color stop.
Something like "red 10% 40%" is just shorthand for "red 10%, red 40%".
|
|
This is an easy check to add and seems like it makes things a
tiny bit smoother.
|
|
|
|
The only accepted syntax for these seems to be
<color> <length percentage> <length percentage>, no other order.
But that's just gathered from looking at other browsers as though
these are supported by all major browsers, they don't appear in
the W3C spec.
|
|
Instead of having "Flip Horizontally" in both the Image and Layer menus,
we now have "Flip Image Horizontally" and "Flip Layer Horizontally".
This same concept applied to other, similar actions.
|
|
|
|
This avoids a jarring effect where we'd "snap" the image into place
upon the next resize event.
|
|
|
|
This will make undoing a resize or rotate operation actually restore the
size of the image as well.
|
|
Computation from last turn might have produced some nodes that are still
accurate. Keeping them should make the engine a bit smarter.
|
|
Monte-Carlo methods are known to intensively create nodes and in our
case each leaf of the tree stores a board. However, for this use case,
we don't need a full board object that also contains game information.
This patch adds a `clone_cleared()` method that return a clone without
game information and uses it when constructing the tree.
It allows the ChessEngine much more possibility before getting out of
memory.
|
|
This method temperate the habit of Monte-Carlo based algorithms to
repeatedly create new nodes.
It was first implemented in `Efficient Selectivity and Backup Operators
in Monte-Carlo Tree Search` by Rémi Coulom.
|
|
|
|
And also add a couple of images so there's more than one option. :^)
(My yak silhouette isn't very good, so please replace that, artists!)
|
|
This was giving wonky results with images that do not fill the entire
card - and it's also unnecessary, since the Buggie image we have been
using, and the two I will be adding, are all small enough to not need
scaling anyway. :^)
|
|
`CardPainter::set_background_image_path()` immediately repaints the card
back and inverted card back bitmaps if they exist, so users just need
to `update()` that part of the screen. This is handled automatically by
`CardGame`, but other users will have to do this manually.
|
|
Instead of each card being responsible for painting its own bitmaps, we
now have a CardPainter which is responsible for this. It paints a given
card the first time it is requested, and then re-uses that bitmap when
requested in the future. This saves memory for duplicate cards (such as
in Spider where several sets of the same suit are used) or unused ones
(for example, the inverted cards which are only used by Hearts). It
also means we don't throw away bitmaps and then re-create identical
ones when starting a new game.
We get some nice memory savings from this:
| | Before | After | Before (Virtual) | After (Virtual) |
|:----------|---------:|---------:|-----------------:|----------------:|
| Hearts | 12.2 MiB | 9.3 MiB | 25.1 MiB | 22.2 MiB |
| Spider | 12.1 MiB | 10.1 MiB | 29.2 MiB | 22.9 MiB |
| Solitaire | 16.4 MiB | 9.0 MiB | 25.0 MiB | 21.9 MiB |
All these measurements taken from x86_64 build, from a fresh launch of
each game after the animation has finished, but without making any
moves. The Hearts value will go up once inverted cards start being
requested.
|
|
Because `card->value() == 11` is a lot less clear than `card->rank() ==
Cards::Rank::Queen`, and also safer.
Put this, along with the `Suit` enum, in the `Cards` namespace directly
instead of inside `Cards::Card`. Slightly less typing that way.
|
|
|
|
|
|
|
|
For now, the only feature of this is that it sets the background colour
from the `Games::Cards::BackgroundColor` config value. Later, other
card game configuration and shared behaviour can go here, to save
duplicating it in each game.
|
|
This currently has exactly one setting: The background colour for card
games. My thinking is, it's better to not have a Settings application
for each individual game we include in the system, since most will only
have a small number of settings, all Settings windows have tabs anyway,
and I don't want to flood the Settings app list unnecessarily.
As for having a single setting for all the card games: it's nice when
things match. :^)
|
|
Before this change, creating a layer, painting something on it and
undoing would delete the layer as well as the paint on it.
|
|
Previously the utf8_view was validated for the utf16 valude instead
of the utf16_view.
|
