| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| | |
This will avoid drawing Arcs if there's no border-radius property set.
Fixes #4127
|
| | | |
|
| | |
| |
| |
| | |
This will avoid drawing Arcs if there's no border-radius property set.
|
| |/
|
|
|
|
|
|
|
| |
This adds the infrastructure necessary to support stacking contexts that
are not containing blocks for absolutely-positioned elements. Our
infrastructure did not support that before. This minor revamp actually
ended up simplifying the logic around display list building and
stacking-relative position computation for absolutely-positioned flows,
which was nice.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is a first stab at implementing border-radius. It looks fine as long as
the border isn't an ellipse (that might not even parse yet), and the border-widths
around a border-radius are the same.
Here's a cool screenshot!
r? @pcwalton @SimonSapin
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first-class.
This implements the scheme described here:
https://groups.google.com/forum/#!topic/mozilla.dev.servo/sZVPSfPVfkg
This commit changes Servo to generate one display list per stacking
context instead of one display list per layer. This is purely a
refactoring; there are no functional changes. Performance is essentially
the same as before. However, there should be numerous future benefits
that this is intended to allow for:
* It makes the code simpler to understand because the "new layer needed"
vs. "no new layer needed" code paths are more consolidated.
* It makes it easy to support CSS properties that did not fit into our
previous flat display list model (without unconditionally layerizing
them):
o `opacity` should be easy to support because the stacking context
provides the higher-level grouping of display items to which opacity
is to be applied.
o `transform` can be easily supported because the stacking context
provides a place to stash the transformation matrix. This has the side
benefit of nicely separating the transformation matrix from the
clipping regions.
* The `flatten` logic is now O(1) instead of O(n) and now only needs to
be invoked for pseudo-stacking contexts (right now: just floats),
instead of for every stacking context.
* Layers are now a proper tree instead of a flat list as far as layout
is concerned, bringing us closer to a production-quality
compositing/layers framework.
* This commit opens the door to incremental display list construction at
the level of stacking contexts.
Future performance improvements could come from optimizing allocation of
display list items, and, of course, incremental display list
construction.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This implements the CSS `linear-gradient` property per the CSS-IMAGES
specification:
http://dev.w3.org/csswg/css-images-3/
Improves GitHub.
|
| |
|
|
|
| |
significantly by giving tiles some time to paint before we render
unrendered content.
|
| | |
|
| | |
|
| |
|
