I've been working on a redesign of the compositor, in order to make
rust-layers more functional as a standalone library and also to simplify
ownership of the layer tree. In the current design, there are two
parallel trees, one of rust-layer ContainerLayers/TextureLayers and one
of servo CompositorL
On 06/30/2014 10:14 PM, Cameron Zwarich wrote:
> We discussed this a bit on #servo, but it isn’t obvious from your
> diagram if every Layer will have child layers, or if that will be
> reserved for specific container layers.
The way I've designed it now, TileLayers are not siblings of
ContainerLay
This is just an informational message to inform everyone of the design
of current scrolling model. I hope this will also be useful to shine the
way toward overflow:scroll. I'm also interested in hearing about
potential improvements to this model, because it would be best to
implement them now, befo
On 11/11/2014 01:19 PM, Patrick Walton wrote:
> Incidentally, I see no reason to move away from Azure, given how nice
> Direct2D is on Windows. Nor do I think that it realistically makes sense
> to write our own rasterizer, given that we have no reason to believe
> that we'll do better than Direct2
This week I took some time to produce updated versions of Skia and
rust-azure for use in Servo. I'd be really happy if people could do some
minor smoke testing before I create PRs for updating Servo itself. There
are branches available at:
https://github.com/mrobinson/skia/tree/upstream-2014-06-16
I wrote a small document about the current design of the compositor and
frame handling in Servo. Hopefully this will be useful to some of you. I
plan to add this to the wiki or to the source tree as documentation. I'd
first like to give people a chance to give feedback, since I've almost
certainly
On 08/20/2015 08:50 AM, Ms2ger wrote:
> Hi all,
>
> Recently, homu has regularly rejected PRs to rust-layers because of a
> mismatch between the latest Rust nightly (which Travis uses by
> default), and Aster (which it depends on through euclid and
> serde_macros). This has been solved by locking
I'm working on fixing the implementation of inline stacking contexts. So
far, I have followed the behavior of Gecko and Chrome which seem to be
to order inline stacking contexts along with block elements that
establish stacking contexts and on top of other inline elements.
By way of example:
Every node and flow tree element (Flows and Fragments) have a bitflag
which tracks the type of damage caused by restyling and DOM
manipulation. This flag is used during incremental layout to only repair
parts of the tree that actually need it. There is a class of bugs where
damage is applied too li
Hello Servo people! I've been working on a proof of concept for a new
display list design. Instead of representing the display list as a tree
of stacking concepts, all display list items are stored in a flat list.
The idea behind this experiment is that one day the flow tree will
produce a flat lis
On 01/25/2016 08:27 PM, Patrick Walton wrote:
> Exciting, thanks a ton for your work here!
>
> I'm guessing that number_of_pseudo_contexts exists so that when a new
> pseudo-SC is created we know what index to assign it?
This is useful during the creation of a new real stacking context or a
pseud
11 matches
Mail list logo
