Instead of exposing many different kinds of messages to the compositor
that are routed through the constellation, expose a single message type
which can be sent across IPC channels. In addition, this IPC channel and
the route to the crossbeam channel with the compositor is created along
with the `CompositorProxy`, simplifying what needs to be passed around
during pipeline initialization.
Previously, some image updates (from video) were sent over IPC with a
special serialization routine and some were sent via crossbeam channels
(canvas). Now all updates go over the IPC channel `IpcSharedMemory` is
used to avoid serialization penalties. This should improve performance
and reduce copies for video, but add a memory copy overhead for canvas.
This will improve in the future when canvas renders directly into a
texture.
All-in-all this is a simplification which opens the path toward having a
standard compositor API and reduces the number of duplicate messages and
proxying that had to happen in libservo.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Instead of exposing many different kinds of messages to the compositor
that are routed through the constellation, expose a single message type
which can be sent across IPC channels. In addition, this IPC channel and
the route to the crossbeam channel with the compositor is created along
with the `CompositorProxy`, simplifying what needs to be passed around
during pipeline initialization.
Previously, some image updates (from video) were sent over IPC with a
special serialization routine and some were sent via crossbeam channels
(canvas). Now all updates go over the IPC channel `IpcSharedMemory` is
used to avoid serialization penalties. This should improve performance
and reduce copies for video, but add a memory copy overhead for canvas.
This will improve in the future when canvas renders directly into a
texture.
All-in-all this is a simplification which opens the path toward having a
standard compositor API and reduces the number of duplicate messages and
proxying that had to happen in libservo.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This changes modifes the way that font data is sent over IPC channels.
Instead of serializing the data or sending it via IPC byte senders, font
data is copied into shared memory and a copy of the handle is sent over
the channel.
There is also the idea of sending the file handle of the on disk data of
system fonts. This could be implemented as a further followup once there
is an abstraction in `ipc-channel` over file handles.
To accomplish this, a `FontData` abstraction is added, which also allows
caching an in-memory shared `Arc<Vec<u8>>` version of the data (neeeded
by some APIs). This could also be a place for caching font tables in the
future.
Finally, the `FontCacheThread` is renamed to the `SystemFontService`
while the proxy for this is now named `SystemFontServiceProxy`.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
This fixes various unused code warnings after the recent rust upgrade.
Some of the dead code is maintained, as it is quite likely that it will
be used in future changes.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This crate only takes care of fonts now as graphics related things are
split into other crates. In addition, this exposes data structures at
the top of the crate, hiding the implementation details and making it
simpler to import them.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
* Move WebRender related types to `webrender_traits`
This refactor moves several WebRender related types
from `compositing_traits`, `script_traits` and `net_traits`
crates to the `webrender_traits` crate.
This change also moves the `Image` type and associated
function out of `net_traits` and into the `pixels` crate.
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
* Move `script_traits::WebrenderIpcSender` to `webrender_traits::WebRenderScriptApi`
---------
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
For a long time, `gfx_traits` has held a lot of things unrelated to graphics
and also unrelated to the `gfx` crate (which is mostly about fonts).
This is a cleanup which does a few things:
1. Move non `gfx` crate things out of `gfx_traits`. This is important in
order to prevent dependency cycles with a different integration between
layout, script, and fonts.
2. Rename the `msg` crate to `base`. It didn't really contain anything
to do with messages and instead mostly holds ids, which are used
across many different crates in Servo. This new crate will hold the
*rare* data types that are widely used.
Details:
- All BackgroundHangMonitor-related things from base to a new
`background_hang_monitor_api` crate.
- Moved `TraversalDirection` to `script_traits`
- Moved `Epoch`-related things from `gfx_traits` to `base`.
- Moved `PrintTree` to base. This should be widely useful in Servo.
- Moved `WebrenderApi` from `base` to `webrender_traits` and renamed it
to `WebRenderFontApi`.
* script: Do not run layout in a thread
Instead of spawning a thread for layout that almost always runs
synchronously with script, simply run layout in the script thread.
This is a resurrection of #28708, taking just the bits that remove the
layout thread. It's a complex change and thus is just a first step
toward cleaning up the interface between script and layout. Messages are
still passed from script to layout via a `process()` method and script
proxies some messages to layout from other threads as well.
Big changes:
1. Layout is created in the script thread on Document load, thus every
live document is guaranteed to have a layout. This isn't completely
hidden in the interface, but we can safely `unwrap()` on a Document's
layout.
2. Layout configuration is abstracted away into a LayoutConfig struct
and the LayoutFactory is a struct passed around by the Constellation.
This is to avoid having to monomorphize the entire script thread
for each layout.
3. Instead of having the Constellation block on the layout thread to
figure out the current epoch and whether there are pending web fonts
loading, updates are sent synchronously to the Constellation when
rendering to a screenshot. This practically only used by the WPT.
A couple tests start to fail, which is probably inevitable since removing
the layout thread has introduced timing changes in "exit after load" and
screenshot behavior.
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
* Update test expectations
* Fix some issues found during review
* Clarify some comments
* Address review comments
---------
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
* remove event_loop_waker that is always None
* remove None event_loop_waker form InitialScriptState
* fix formatting
* remove None event_loop_waker from ScriptThread
* remove None EventLoopWaker from Window
* remove None and use of wake_after_send in webgl code
There are a few canvas2d-related dependencies that haven't updated, but they
only use euclid internally so that's not blocking landing the rest of the
changes.
Given the size of this patch, I think it's useful to get this landed as-is.
Clean-up navigation
<!-- Please describe your changes on the following line: -->
1. Navigation as a result of following a hyperlink should be done in a task: https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks:dom-manipulation-task-source
2. The javascript url navigation should also be done in a task: https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:dom-manipulation-task-source
3. In `window.load_url`, it seems there is no need to send a message to the script-thread(the entirety of `load_url` should instead be done in a task when appropriate), so we can just do that last part "sync" by calling a method on the script, which will send a message to the constellation(for the parallel navigation steps), or queue task(for the JS navigation), as appropriate.
4. Separate the "normal" navigation flow from the handling of "navigate an iframe" message from constellation, since doing everything in one method as was previously done with `handle_navigate`, is confusing.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23368)
<!-- Reviewable:end -->
security: check target and source origin before executing JS url
implement replacement-enabled flag as a HistoryEntryReplacement enum
add source origin string on loaddata
add LoadOrigin
iframe: remove optional load-data
auxiliaries: add load-data into info
constellation: remove url from Pipeline::new
check load origin: link to whatwg issue
switch loadorigin toplevel to constellation
This module adds a structure (WindowGLContext) which holds the
OpenGL parameters that are going to be used by servo-media player
to render video frames using OpenGL.
In order to fill this structure, three new methods were added to
WindowMethods trait. In this patch only the Glutin-based
implementation provides a simple boilerplate.
The WindowGLContext is created in the entry point of libservo, when
the application window is created, and later passed to the
constellation, the pipeline and to the window element in dom, thus
htmlmediaelement has a mean to obtain these parameters via its
window.
