This should be the final PR for the Hash Function series that is
trivial.
Of note: I decided to transform `HashMapTracedValues<Atom,..>` to use
FxBuildHasher. This is likely not going to improve performance as Atom's
already have a unique u32 that is used as the Hash but it safes a few
bytes for the RandomState that is normally in the HashMap.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Testing: Hash function changes should not change functionality, we
slightly decrease the size and unit tests still work.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
There were still some accesses to the inner BrowsingContextId from the
WebViewId. This changes it to completely rely on the From trait for
these methods. This also means we can make the field private.
For testing we add a way to create arbitrary WebViewIds.
Testing: Does not change functionality.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Adds a new memory report that aggregates the size of all scroll trees
from within all pipelines for each web view.
Testing: Acessing `about:memory`
Fixes: #38726
---------
Signed-off-by: criskell <96352451+criskell@users.noreply.github.com>
["When applicable, unstable sorting is preferred because it is generally
faster than stable sorting and it doesn’t allocate auxiliary
memory."](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.sort)
Binary also reduced by 1KB in Release.
Testing: No behaviour change as semantically all current usage does not
have any pair with `std::cmp::Ordering::Equal`.
Signed-off-by: Euclid Ye <euclid.ye@huawei.com>
Rather than creating unique types for each pipeline-namespaced index
type (eg. MessagePortId, DomExceptionId, etc.), we can create a generic
common type that uses a marker to prevent type confusion. This change
allows us to reduce the boilerplate code required when implementing
serializable/transferable interfaces, since the structured clone
implementation can rely on the common type.
Testing: Existing WPT tests for serialization and transferring provide
coverage.
---------
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
There is a `WebView` in libservo (new) and a `WebView` in compositing
(old). Nowadays, the "real" `WebView` is the one in the libservo. The
`WebView` in `compositing` is really about rendering the contents of a
`WebView` from libservo. In addition there is also a trait exposed by
the compositor called `RendererWebView` which is a way for the
compositor to talk to libservo without a circular dependency.
This changes does some renames to make things clearer and so that there
is One Less WebView™:
- `compositing::WebView` -> `compositing::WebViewRenderer` (this is the
same kind of naming as `ServoRenderer`).
- `compositing::RendererWebView` -> `compositing::WebViewTrait`
Testing: This is just a couple renames so should be covered by existing
tests.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Create a separate file for `WebviewManager` to improve clarity.
Testing: This change is just a refactor, so no new tests are needed.
Signed-off-by: Shubham Gupta <shubham13297@gmail.com>