On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote:
> On 2/13/14 5:56 PM, Robert O'Callahan wrote:
>
>> 2) Fragmentation. With something like overflow:fragments, absolute
>> positioning can affect the number of fragments you generate, which can
>> affect the size of the container of the fragmen
On Fri, Feb 14, 2014 at 12:53 PM, Patrick Walton wrote:
> For the first concern, I realized that pages like that are going to be
> sequential no matter what we do, of course, because of the way parallel
> tree traversals work. So never mind there. The O(n^2) update of overflow
> areas still concer
On 2/13/14 6:45 PM, Patrick Walton wrote:
1. This creates multiple sequential barriers, which can result in a
parallelism hazard. As an extreme case, consider:
div { position: absolute; }
...
This will effectively result in fully sequential layout because you have
to wait until layou
On 2/13/14 5:56 PM, Robert O'Callahan wrote:
2) Fragmentation. With something like overflow:fragments, absolute
positioning can affect the number of fragments you generate, which can
affect the size of the container of the fragments.
Ugh. I thought one of the points of absolute positioning was
Here's an idea for how to leverage the leaf-set-removal proposal to optimize
this algorithm:
1. When assigning widths for parents, don't enqueue absolutely positioned kids
to have their widths assigned.
2. Absolutely positioned kids of a node should not be counted as outstanding
children-to-be
For the first concern, I realized that pages like that are going to be
sequential no matter what we do, of course, because of the way parallel tree
traversals work. So never mind there. The O(n^2) update of overflow areas still
concerns me though.
Patrick Walton wrote:
>On 2/13/14 2:42 PM, Bor
On 2/13/14 2:42 PM, Boris Zbarsky wrote:
Then you go through this list (this part should parallelize pretty
nicely, btw, except for the overflow area updates on parents) and reflow
them all, since now you know their containing block sizes, and you
update overflow areas. Again, if there are abs p
> Let me use this opportunity to remind people that fragmentation and
> writing-mode are stuff we should be building into Servo now-ish because
> they affect everything else.
writing-mode is already on the list for next quarter, but fragments is
slated for the quarter after that. I'll try and bump
> By contrast, approach #1 (Gecko's approach) avoids the unbounded amount of
> information flow in the opposite direction to the traversal. The height and
> overflow region only need to travel one step: from containing block to its
> immediate absolutely positioned flow child and back. This can be
On Fri, Feb 14, 2014 at 11:42 AM, Boris Zbarsky wrote:
> On 2/13/14 4:48 PM, Patrick Walton wrote:
>
>> The pull request #1681 takes approach #2. It deals with the parallel
>> hazard by deferring height computation of absolutely positioned blocks
>> until display list construction time (which is
On 2/13/14 4:48 PM, Patrick Walton wrote:
The pull request #1681 takes approach #2. It deals with the parallel
hazard by deferring height computation of absolutely positioned blocks
until display list construction time (which is top-down).
I sort of think that the right time to do absolutely po
Hi everyone,
Pradeep's excellent pull request [1] for absolute positioning raised
some thorny issues relating to solving geometry constraints for
absolutely positioned blocks in a parallel setting. The fundamental
issue is that absolute positioning can depend not only on width and
height of t
I suspect the main issue will just be getting a reliable cross
compiler on ARM for the arm linux ABI. I think Luqman has been working
on that, but IRC (#rust or #rust-internals) or the rust-dev mailing
list may be a better place to ask.
jack.
On Thu, Feb 13, 2014 at 6:16 AM, Edit Balint wrote:
>
Dear Servo Developers!
My name is Edit Balint, I'm a software developer at University of
Szeged, Hungary.
We have a research project regarding Servo and Rust.
Our main goal is to cross-compile and run Servo on ARM Linux (not Android).
We have several issues with the cross-compiling procedure. I
14 matches
Mail list logo
