We currently have a handful of iframe tests whose sources are in the
"input" directory. This means they get run as their own tests, when they
are really just helper files. We've had to add empty test expectation
files for these "tests", and invoke a dummy test() method just to keep
the test runner happy.
Instead, move them to their own directory so the test runner does not
see them at all.
This patch builds off the previous commit and removes the mouse hacks
entirely as they are not needed anymore.
With this, Sonic Robo Blast 2 now correctly locks the mouse inside the
game and makes for a much better playing experience! :^)
This patch implements the mouse warping functionality of SDL2.
This adds a WarpMouse function implementation to the SDL2 port.
SDL2 will then be able to use this for it's relative mouse mode
implementation.
With this, multiple ports depending on SDL2 now correctly lock the
mouse inside the window and it improves the experience significantly.
Note that as of now, you may need to pass the kernel argument
'vmmouse=off' in order to test these changes properly.
This implements support for `glBlendEquation` and
`glBlendEquationSeparate`. These functions modify the calculation of the
resulting color in blending mode.
This patch moves us away from the accumulator-based bytecode format to
one with explicit source and destination registers.
The new format has multiple benefits:
- ~25% faster on the Kraken and Octane benchmarks :^)
- Fewer instructions to accomplish the same thing
- Much easier for humans to read(!)
Because this change requires a fundamental shift in how bytecode is
generated, it is quite comprehensive.
Main implementation mechanism: generate_bytecode() virtual function now
takes an optional "preferred dst" operand, which allows callers to
communicate when they have an operand that would be optimal for the
result to go into. It also returns an optional "actual dst" operand,
which is where the completion value (if any) of the AST node is stored
after the node has "executed".
One thing of note that's new: because instructions can now take locals
as operands, this means we got rid of the GetLocal instruction.
A side-effect of that is we have to think about the temporal deadzone
(TDZ) a bit differently for locals (GetLocal would previously check
for empty values and interpret that as a TDZ access and throw).
We now insert special ThrowIfTDZ instructions in places where a local
access may be in the TDZ, to maintain the correct behavior.
There are a number of progressions and regressions from this test:
A number of async generator tests have been accidentally fixed while
converting the implementation to the new bytecode format. It didn't
seem useful to preserve bugs in the original code when converting it.
Some "does eval() return the correct completion value" tests have
regressed, in particular ones related to propagating the appropriate
completion after control flow statements like continue and break.
These are all fairly obscure issues, and I believe we can continue
working on them separately.
The net test262 result is a progression though. :^)
This is pure prep work for refactoring the bytecode to use more operands
instead of only registers.
generate_bytecode() virtuals now return an Optional<Operand>, and the
idea is to return an Operand referring to the value produced by this
AST node.
They also take an Optional<Operand> "preferred_dst" input. This is
intended to communicate the caller's preference for an output operand,
if any. This will be used to elide temporaries when we can store the
result directly in a local, for example.
The JIT compiler was an interesting experiment, but ultimately the
security & complexity cost of doing arbitrary code generation at runtime
is far too high.
In subsequent commits, the bytecode format will change drastically, and
instead of rewriting the JIT to fit the new bytecode, this patch simply
removes the JIT instead.
Other engines, JavaScriptCore in particular, have already proven that
it's possible to handle the vast majority of contemporary web content
with an interpreter. They are currently ~5x faster than us on benchmarks
when running without a JIT. We need to catch up to them before
considering performance techniques with a heavy security cost.
This can apply to optional, nullable parameters of platform types. This
will cause the generator to generate the type as
Optional<JS::GCPtr<T>> rather than JS::GCPtr<T>, allowing the
implementation to differentiate between the case where the argument was
not passed, and the case where null or undefined was passed.
Needing to differentiate these two cases is quite niche, hence why it is
an opt-in behavior.
When an <input type=image> button is clicked, we now send the (x,y)
coordinates of the click event (relative to the image) along with the
form submission data.
Regarding the text test, we can currently only test this feature with
dialogs. The headless-browser test infrastructure cannot yet handle the
resulting navigation that would occur if we were to test with normal
form submission.
HTMLFormElement::elements is not the correct filter for submittable
elements. It includes non-submittable elements (HTMLObjectElement) and
also excludes submittable elements (HTMLInputElements in the "image"
type state, "for historical reasons").
This implements enough to represent <input type=image> with its loaded
source image (or fallback to its alt text, if applicable). This does not
implement acquring coordinates from user-activated click events on the
image.
They currently assume the DOM node is an HTMLImageElement with respect
to handling the alt attribute. The HTMLInputElement will require the
same behavior.
Previously, when constructing an XML document, the default namespace
was the empty string. This led to XML documents having empty xmlns
attributes when serialized.
Previously, CDATASection nodes were being serialized as if they were
text, which meant they were missing their start and end delimiters.
Occurrences of the '&', '<' and '>' characters were also being replaced
with their entity names.
The DOM specification states that: "Unless stated otherwise, a
document’s [...] type is 'xml'".
Previously, calls to `Document::document_type()` were returning the
incorrect value for non-HTML documents.
Our current CLUT code is pretty slow. A one-element cache can make
it quite a bit faster for images that have long runs of a single
color, such as illustrations.
It also seems to help with photos some (in `0000711.pdf` page 1) --
I suppose even them have enough repeating pixels for it to be worth
it.
Some numbers, with `pdf --render-bench`:
`0000711.pdf --page 1` (high-res photo)
before: 2.9s
after: 2.43s
`0000277.pdf --page 19` (my nemesis PDF, large-ish illustration)
before: 2.17s
after: 0.58s (!)
`0000502.pdf --page 2` (wat hoe dat)
before: 0.66s
after: 0.27s
`0000521.pdf --page 10 ` (japanese)
before: 0.52s
after: 0.29s
`0000364.pdf --page 1` (4 min test case)
before: 0.48s
after: 0.19s
Thanks to that last one, reduces the time for
`time Meta/test_pdf.py ~/Downloads/0000` from 4m22s to 1m28s.
Helps quite a bit with #23157 (but high-res photos are still too
slow).
This reverts commit a4b2e5b27b.
This was just plain wrong, I remember it making sense and fixing
something but that was probably due to local changes. It should never
have landed on master, my bad.
According to the Intel Software Developer's Manual Volume 3A section
6.12.1.3, the interrupt gate type means the IF flag is cleared to
prevent nested interruption. The trap gate type does not modify the
IF flag. Thus the gate type argument is important when constructing
an IDTEntry.
On x86_64 and x86, storage_segment (bit 12 counting from 0)
is always 0 according to the Intel Software Developer's Manual,
volume 3A, section 6.11 and section 6.14.1. It has therefore
been removed as a parameter from IDTEntry's constructor and
hardwired to 0.
