Thanks David! I like the idea of moving the class-specific bits into the new area--It buys us more time for those classes. I'll test to see if the perf hit is significant when we always fetch from the new bits vs. first checking for the presence of extended bits.
--Jet On Sat, Feb 13, 2016 at 6:21 PM, L. David Baron <dba...@dbaron.org> wrote: > On Saturday 2016-02-13 18:13 -0800, Jet Villegas wrote: > > Hi All: > > > > While hacking on bug 1242461, I ran into the issue where our 64 bits of > > nsFrame and nsBlockFrame state are used up. To resolve this, and I was > > thinking I could reuse bit 59 to indicate NS_FRAME_EXTENDED_BITS and > > allocate another uint32 or uint64 for those bits. Has someone already > tried > > this? Will the memory hit be unacceptable? > > I don't think it should be separately allocated; it should just be a > fully-fledged part of nsIFrame. > > It looks like there's a 32-bit gap on 64-bit builds next to > mOverflow, and we should probably just put another 32 bits of frame > state bits there (after double-checking this). We might want to > separate the class-specific bits into that new 32-bit value, > although I'm less sure about that. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) > _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
