Figure out if Servo can just communicate iframe resizes to itself instead of relying on WebRender

[jrmuizel]

Currently WebRender sends a FrameSize message to the constellation when it detects an Iframe resize. It seems like any consumers of this should be getting the information directly from layout instead of indirectly via WebRender.

@jdm

[jdm]

I do not see any reason it needs to be structured this way. The layout thread creates display items for each iframe that get passed directly to WR, and WR stores the LayerSize values in a hashmap unmodified. These values are passed unmodified by WR to the pipeline_size_changed notification in the compositor, which sends them unmodified to the constellation. Finally in the constellation they are sent to the script thread, which uses them to resize things.

Since the constellation already has a hashmap of pipelines that contains a size, we could theoretically send them from layout to the constellation and do the checking there. This should let us remove all the related code from WR.

[cynicaldevil]

Right, I'm taking this one!

[cynicaldevil]

Since this will introduce changes in both servo's and webrender's repos, how will the bot build/test these changes?

[jdm]

The bot can't test it unless you publish a fork of webrender with your changes (or they get merged into the original) and the PR includes an update to the WR revision.

[glennw]

My suggestion would be to change Servo to work without using the WR APIs at all first. Then we could actually land this without any changes to WR. Once that work is done, we could remove the deprecated WR APIs as a follow up, which will then have no effect on Servo since they are unused.

[cynicaldevil]

I'm sending a resize message from layout to constellation in compute_abs_pos_and_build_display_list here, where the layout thread also sends the display list to WR.

Later, I compare the size I sent in the message to constellation to the old size here. But when I check the debug logs, I notice that the two sizes are always equal. Am I correct in assuming that pipeline.size contains the old size?

[jdm]

I believe the problem is that sending the viewport size from layout to the constellation is self-fulfilling - the viewport is provided to layout by the script thread, and was provided to the script thread by the constellation. Instead, when layout encounters an iframe element and determines its size, it should inform the constellation of the iframe's dimensions for the pipeline contained inside of the iframe.

[cynicaldevil]

@jdm What do you mean by pipelines contained inside the iframe?

[jdm]

An iframe embeds one document inside of another. Each document has a corresponding pipeline, therefore there is a pipeline associated with the child document embedded in the iframe.

[cynicaldevil]

I don't know if I understood this right, but we were checking whether there was a mismatch in the old and new sizes and updating the frame size itself. Why do we want to update the children's sizes in this refactor?

[jdm]

For a document A that contains an iframe embedding document B, there are two layout threads. The viewport size of document B depends on the size of the iframe calculated by the layout thread for document A.

In Servo master, the layout thread for document A sends a display list to the compositor that includes the iframe size, and at some point WebRender sees this and checks whether that iframe changed sizes. It then notifies the compositor, which notifies the constellation, which sends a resize message to the script thread for document B. Next time layout happens for document B, the layout thread is informed of the updated viewport size.

In the new model that excludes WebRender, the layout thread for document A still has the information about the iframe size. The layout thread for document B will not receive an updated viewport size unless the constellation finds out about document A's iframe size, so it can propagate that information to document B's script thread. Does that make sense?

[cynicaldevil]

Doesn't layout thread send the display list to WR instead of the compositor?

[jdm]

That may be the case, yes.

[cynicaldevil]

Ah, it makes sense now. Thanks!

[cynicaldevil]

@jdm handle_frame_size_msg now sends messages to children iframes here.

I tested tests/wpt/mozilla/tests/mozilla/window_resize_not_triggered_on_load.html and pasted the debug output here. I'm having trouble reading the logs, I don't know what I should be looking for. Help?

[jdm]

If you want debug logs, it's better to select the modules that will actually be useful (eg. RUST_LOG=constellation::constellation,layout_thread,script::script_thread). If you'd like assistance, please explain what you're having difficulty figuring out based on the logging output and what you expect to be seeing?

[cynicaldevil]

I've changed the code so that the display list is checked in handle_reflow and a resize message is sent if the display item is an iframe. But when I run the tests, the display list isn't updated at all. Because of this, the child iframe doesn't receive the constrained viewport message at all.
I performed a diff after adding a few debug messages of my own to print the display list: https://www.diffchecker.com/ePu6XPte

[jdm]

The debug messages show that the existing pipeline size in the constellation is always None. This means that cynicaldevil@fd427ea#diff-55c92a6a5ba7654ce45fe6fc6c63740fR1336 skips the code that updates the current size and the resize message is never sent.

[jdm]

#15129 was reverted as part of #15164.

[emilio]

Trying to reland them in #15186

[emilio]

Relanded