Free some frame bits for anchor positioning.
Categories
(Core :: Layout, defect, P3)
Tracking
()
| 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.
- It seems that
NS_FRAME_HAS_VIEWcould be removed fairly trivially as it only applies to a very small number of frames nowadays: https://searchfox.org/firefox-main/rev/dc1c78e9c37aba6ed05a4ec47c4bfcb16f57b51d/layout/generic/nsIFrame.cpp#7798-7802,7809. We could make it a frame class flag (MayHaveView or somesuch) - NS_FRAME_INDEPENDENT_SELECTION too unless I'm missing something (it's basically nsTextControlFrame | nsListControlFrame right?)
| Assignee | ||
Updated•4 months ago
|
Updated•4 months ago
|
Comment 1•4 months ago
|
||
(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.
| Assignee | ||
Comment 2•4 months ago
|
||
Ah so the trick is that it gets propagated to children in nsIFrame::Init. But that is fixable, will dig more.
Comment 3•4 months ago
|
||
NS_FRAME_SIMPLE_EVENT_REGIONS seems unused.
Comment 4•4 months ago
|
||
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.
Comment 5•4 months ago
|
||
Updated•4 months ago
|
Comment 7•4 months ago
|
||
(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.
Comment 8•4 months ago
|
||
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.
Comment 9•4 months ago
|
||
| bugherder | ||
| Assignee | ||
Comment 10•4 months ago
|
||
| Assignee | ||
Comment 11•4 months ago
|
||
The subdocument frame caller is a no-op because nsSubdocumentFrame is a
leaf frame.
| Assignee | ||
Comment 12•4 months ago
|
||
It doesn't have an independent selection. Only nsTextControlFrame has a
different nsISelectionController.
| Assignee | ||
Comment 13•4 months ago
|
||
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.
| Assignee | ||
Comment 14•4 months ago
|
||
(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...
Comment 15•4 months ago
|
||
Comment 16•4 months ago
|
||
Comment 17•4 months ago
|
||
Updated•4 months ago
|
Updated•4 months ago
|
Comment 18•4 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/64b8cb06af39
https://hg.mozilla.org/mozilla-central/rev/44b5ed772ed5
https://hg.mozilla.org/mozilla-central/rev/6f62ff18e12e
https://hg.mozilla.org/mozilla-central/rev/c836d1ea5c4f
Updated•3 months ago
|
Description
•