Please do not add a new WebViewDelegate method for this, as now the embedder needs to implement two things in order to properly communicate window sizes. Instead in libservo, somehow access the RenderingContext size and the offset from the existingscreen_geometry() method.

The hidpi_scale_factor is stored in WebViewInner as part of the WebView struct, so you should have access to it in libservo.

Thanks. But RenderingContext/WindowRenderingContext etc. all only holds inner_size, same as the previous compositor proxy.

I also checked WebViewInner.rect, which is supposed to be inner_size rect, but currently heavily & wrongly mix-used.. (Will file an issue tomorrow)

TL;DR: It is still difficult to get outer_size without adding method to WebViewDelegate...

now the embedder needs to implement two things in order to properly communicate window sizes.

I have a idea: remove fn window_rect from WindowPortsMethods added last week in #37812. Just move logic to our newly created WebViewDelegate::window_rect.

This way, we also supports egl.

I see. So the issue is that we really need the outer window rect and also the inner window rect? Can you have ScreenGeometry return this information? I think it makes sense that we get all of this information in a similar place (for now) so that the person embedding Servo understands how all the parts fit together.

/// Information about a `WebView`'s screen and containing window geometry. This
/// is used for the [Screen](https://drafts.csswg.org/cssom-view/#the-screen-interface)
/// CSSOM APIs and `window.screenLeft` / `window.screenTop`.
#[derive(Clone, Copy, Debug, Default)]
pub struct ScreenGeometry {
    /// The size of the screen in device pixels. This will be converted to
    /// CSS pixels based on the pixel scaling of the `WebView`.
    pub size: DeviceIntSize,
    /// The available size of the screen in device pixels. This size is the size
    /// available for web content on the screen, and should be `size` minus any system
    /// toolbars, docks, and interface elements. This will be converted to
    /// CSS pixels based on the pixel scaling of the `WebView`.
    pub available_size: DeviceIntSize,
    /// The rectangle in device pixels of the `WebView`'s containing window on the screen.
    pub window_rect: DeviceIntRect,
    /// The offset of the `WebView` in its containing window in device pixels..
    pub offset_in_window: DeviceIntPoint,

Would that work?

Works like a charm.

I have an important question, given that I encountered several rounding display/layout issues before (e.g. #37243). Should we round or truncate?
They seem to be mix-used in Servo rn. Compositor always truncates. Layout sometimes rounds.
cc @Loirooriol @sagudev

Personally, I tends to keep fractional value as long as possible (like during layout calculation), and round when we have to. Never truncates.

This can be left as an open question. I am only certain that WebDriver set window rect should always round.
Can you review this pls? @mrobinson

This is a good question that I don't know the answer to. :/

This unwrap means that by default Servo will panic as the default implementation of fn screen_geometry returns None. Please do this:

Ok. I wrote like this because all egl/desktop implementation of screen_geometry returns Some.

Sure, but we don't have control over what other embedders do (the embedding API is meant to be generic and public) and the interface allows returning None as a valid response. We need to obey the contract the API gives.

Should round instead of round_out, because we want "as close as possible" as claimed in #37960 (comment) to be consistent with WebDriver get rect. It is ok if things don't fit in.

I search the WebDriver spec for the text "as close as possible" and I only see that this should apply when trying to resize the window. I don't interpret this as referring to rounding floating point pixels though, but for when the operating system imposes other kinds of sizing constraints on the window. In any case, is this terminology used anywhere with regard to actually getting the window's size.

FWIW, I used round_out here as it seemed to make more sense that the rectangle contained the entire window versus just part of it.

But if using round_out, this will start to fail some WebDriver tests. Do you suggest that I change other round to round_out in previous merged PR?

FWIW, I used round_out here as it seemed to make more sense that the rectangle contained the entire window versus just part of it.

But this can also introduce some danger. You may try to paint on larger than available window, leading to some obscured corner. round_in would make more sense to me..

EDIT: Maybe leave as another open question, and use round() for now?

Are these tests using floating point window sizes?

I test on my own high DPR device with headed window. The assertion will be off by 1 with this.

For headless window, this should be fine as DPR is always 1.

The window_size here wasn't 0, but self.inner_size.get().
The coordinates has always been 0 so it's ok.

Good point. This should be fixed now.