On 6/5/13 12:58 PM, Patrick Walton wrote:
Do you mean that having to wipe the parent flow when a child render box
changes is a rare case in general or that this specific case (an inline
becoming non-inline) is rare?
I mean that the latter is rare, so just wiping the parent flow when it
happens
On 6/5/13 8:30 AM, Boris Zbarsky wrote:
On 6/4/13 9:47 PM, Patrick Walton wrote:
We're trying to figure out what to do when an inline RenderBox of an
inline flow becomes non-inline. This is a vexing issue, as it violates
the invariant that a flow's descendants and the flow itself are the only
fl
On 6/4/13 9:47 PM, Patrick Walton wrote:
We're trying to figure out what to do when an inline RenderBox of an
inline flow becomes non-inline. This is a vexing issue, as it violates
the invariant that a flow's descendants and the flow itself are the only
flows that need to be reconstructed from sc
On Jun 4, 2013, at 18:59 , "Robert O'Callahan" wrote:
> On Wed, Jun 5, 2013 at 1:48 PM, Patrick Walton wrote:
>
>> We're trying to figure out what to do when an inline RenderBox of an
>> inline flow becomes non-inline. This is a vexing issue, as it violates the
>> invariant that a flow's desce
On Wed, Jun 5, 2013 at 1:48 PM, Patrick Walton wrote:
> We're trying to figure out what to do when an inline RenderBox of an
> inline flow becomes non-inline. This is a vexing issue, as it violates the
> invariant that a flow's descendants and the flow itself are the only flows
> that need to be
Hi everyone,
We're starting on incremental layout, in order to improve performance of
the layout benchmarks we are most focused on (`test_hammer_layout` and
`test_slam_layout`). It was also felt, based on past experience, that
having incremental layout from the start is important to get in ear
6 matches
Mail list logo
