Closed Bug 1993353 Opened 4 months ago Closed 4 months ago

Free some frame bits for anchor positioning.

Categories

(Core :: Layout, defect, P3)

defect
Points:
1

Tracking

()

RESOLVED FIXED
145 Branch
Tracking Status
firefox145 --- fixed

People

(Reporter: emilio, Assigned: emilio)

References

(Blocks 1 open bug)

Details

(Whiteboard: [anchorpositioning:m2])

Attachments

(5 files)

This has come up a couple time as part of making anchor position code paths not impose perf overhead.

Flags: needinfo?(emilio)
Whiteboard: [anchorpositioning:triage]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #0)

  • NS_FRAME_INDEPENDENT_SELECTION too unless I'm missing something (it's basically nsTextControlFrame | nsListControlFrame right?)

FWIW, this seems like a strong indication.

Ah so the trick is that it gets propagated to children in nsIFrame::Init. But that is fixable, will dig more.

NS_FRAME_SIMPLE_EVENT_REGIONS seems unused.

NS_FRAME_PAINTED_THEBES is only used by tests. Could make it debug only bool on nsIFrame and make the tests debug only?

NS_FRAME_UPDATE_LAYER_TREE is only used on displayroots (viewport and menupopup). Could move it to the frame type specific section of frame state bits?

NS_FRAME_DRAWING_AS_PAINTSERVER does not seem perf critical at all. Could be a frame prop, and we could further reduce the overhead of this since we only need to check it if we are already drawing something as paint server, which could (or might already) store that on the nsDisplayListBuilder.

Keywords: leave-open

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

NS_FRAME_UPDATE_LAYER_TREE is only used on displayroots (viewport and menupopup). Could move it to the frame type specific section of frame state bits?

This one seems pretty easy too, I have a patch for this.

Oh wait, menupopup frame is a block frame, which only has one frame specific bit available, not sure we want to use it for this.

The subdocument frame caller is a no-op because nsSubdocumentFrame is a
leaf frame.

It doesn't have an independent selection. Only nsTextControlFrame has a
different nsISelectionController.

It's only used to check the closest text control. We can abuse the fact
that nsTextControlFrame only has anonymous kids instead to make checking
for a containing text control fast in the common case.

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

Oh wait, menupopup frame is a block frame, which only has one frame specific bit available, not sure we want to use it for this.

It's a bit ugly but why can't we just store the state separately in nsMenuPopupFrame and ViewportFrame? in two separate booleans seems fine...

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/f786affdc7af https://hg.mozilla.org/integration/autoland/rev/44b5ed772ed5 Remove view reparenting code that has been disabled forever. r=tnikkel,layout-reviewers
Keywords: leave-open
Points: --- → 1
Whiteboard: [anchorpositioning:triage] → [anchorpositioning:m2]
QA Whiteboard: [qa-triage-done-c146/b145]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: