This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
No implementation just yet (the default QualifiedRuleParser
implementation just rejects stuff), but this is plumbing that I'd rather
get reviewed separately.
Differential Revision: https://phabricator.services.mozilla.com/D176686
Using the newer version of the crash-context crate corrects the 32-bit Linux context structure,
which was the cause of the IP memory not being stored (among possibly other 32-bit Linux issues).
Differential Revision: https://phabricator.services.mozilla.com/D174314
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
In stead of having the css parser construct a color in it's own format
and then converting it to what Gecko needs to perform operations, we now
construct a Gecko friendly color type directly.
Differential Revision: https://phabricator.services.mozilla.com/D170187
This updates the version wpf-gpu-raster which adds support for
GPUs/drivers that use truncation instead of rounding when converting
vertices to fixed point.
It also adds the GL vendor to InitContextResult so that we can detect
AMD on macOS and tell wpf-gpu-raster that truncation is going to happen.
Differential Revision: https://phabricator.services.mozilla.com/D167503
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
Picks up a single fix to address a deadlock triggered when attempting to
configure an audio device that has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D166736
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
The postprocessing phase that cleaned up `pytoml`'s output has little
effect on `toml`'s output, which is already largely clean. Remove the
additional code.
Differential Revision: https://phabricator.services.mozilla.com/D164153
Remove explicit sorting, as this is no longer needed to guarantee
determinism as of Python 3.6 (our minimum-supported version).
(This is a separate commit solely to make it clear that the reordering
of `.cargo/config.in` is indeed merely a reordering and contains no
hidden functional changes.)
Differential Revision: https://phabricator.services.mozilla.com/D164152
This brings in various bugfixes and improvements from upstream,
including the fix for bug 1791809 and a workaround for bug 1804530.
In this update, `wgpu_core` leaves the selection of backends to its
users, rather than trying to guess which backends to use itself, based
on the target architecture and operating system. For Firefox, this
means that `gfx/wgpu_bindings/Cargo.toml` is now responsible for
selecting back ends.
Firefox's WebGPU implementation should never use `wgpu`'s GLES
backend. Firefox can now explain this to `wgpu-core`, causing it to
drop its dependency on `glow`, `bitflags_serde_shim` and `slotmap`.
These are no longer vendored, and their exemptions in
`supply-chain/config.toml` can be dropped.
The new `wgpu-core` updates to version 0.37.1+1.3.235 of the `ash`
crate, and this patch moves ash's supply-chain exemption forward to
the new version. We expect to finish vetting that next week, but
because this `wgpu-core` update is urgently needed, we want to extend
the exemption for the time being.
The dependency on `slotmap` had been patched to an empty file in
`build/rust/dummy-web`, which can now be removed.
The new `wgpu-core` no longer uses `cfg_aliases`, so Firefox no longer
needs to vendor that.
Differential Revision: https://phabricator.services.mozilla.com/D164928
Started callback interface functionality to UniFFI. Currently this only
supports the async fire-and-forget use case, where Rust queues a JS
function to run, but doesn't wait (or `await`) for the response.
The basic system is:
- The JS code registers a callback interface handler with the C++
code. This handler is responsible for the specifics of invoking the
callback.
- The C++ code defines a function to call a JS handler. Once the JS
handler registers itself with C++, the C++ registers it's function
with Rust.
- The C++ code queues the call to the JS main thread.
- Because of how UniFFI handles callback interfaces, the C++ code can
be "dumb". UniFFI sends a object id, method id, and RustBuffer
encoding all arguments. This means C++ doesn't need to care about
the specific arguments, they get unpacked by JS.
I tried to keep the generated code as simple as possible by moving the
complexity to static code. For JS this meant writing a generic
`UniFFICallbackHandler` class in the static code that the generated code
constructs. For C++ this meant the generated code defines a
`UniFFIGetCallbackInterfaceInfo` function that returns a struct with all
the data specific to a callback interface (it's name, the UniFFI
scaffolding init function, etc). The static code can then define a
generic `QueueCallback` function that looks up the callback interface
info using the interface ID and then makes the call.
Allow UniFFI functions to run on the main thread rather than always
being dispatched to a worker thread. This allows us to test invoking
callback interfaces from the main thread thread. I don't think we will
use this much currently, since we don't want to block the main thread
for any significant amount of time. However, this will pair well with
the next step in the project which is async -- allowing async Rust
functions to call async JS functions. In that scenario, dispatching to
the worker thread is unnecessary.
Callback interface objects present a potential memory leak, since you
can easily create a cycle between a JS Callback object and a UniFFIed
Rust object, and the GC has no way of detecting it. To try to detect
these there's some shutdown code that checks that there are no callbacks
registered during shutdown and prevents any future callbacks from being
registered.
Added a `config.toml` file and code to parse it. This is needed to
specify which functions should run on the main thread.
Updated the git commits for the several UniFFI examples/fixtures.
Differential Revision: https://phabricator.services.mozilla.com/D156116
This adds machinery to wpf-gpu-raster and aa-stroke to support an output buffer specified as
a slice, which they will preferentially use instead of their dynamic Vec to store output
vertexes in.
Differential Revision: https://phabricator.services.mozilla.com/D163989
This modifies AddInterval in wpf-gpu-raster to try to remember the last interval
it searched for so that it doesn't have to search the entire interval list for
every interval added. This should take us down from O(n^2) to closer to O(n) for
this phase of rasterization.
Differential Revision: https://phabricator.services.mozilla.com/D163795
