For #1406
Not really sure about some of my naming conventions, but offset was kinda taken in box.rs :/
Also this doesn't fully implement the offsets, but I'll do that alongside #782.
The rendergl::render_scene() function is being called more often than it needs to be, sometimes before the renderer has finished. This could result in PNG images that are drawn before the frame trees set in SetIds is rendered.
Pipeline now blocks on `Pipeline.exit()` and waits for confirmation that RenderTask and LayoutTask were successfully destructed (they're created inside a block which ensures they go out of scope before the message is sent.
Other notable changes include:
* The blocking recv in main/servo.rc that waits for a constellation exit confirmation was moved out of the spawn and into the main thread. `Constellation::start()` spawns a new task, so there's no need to block in that task once the ExitMsg is sent off.
* Application initialization was moved out of `run_compositor` and into `CompositorTask`, so it could be stored with the compositor task and not go out of scope until the program's main block finishes.
I had to use SharedPort<()> objects to work around the fact that pipelines get cloned, even though it feels like pipelines should probably be ref counted instead. I went down that route for a few hours but got bogged down trying to wrap my head around some region/lifetime issues; I would be happy to work on that part again, but would need some mentoring to help me figure out what I was doing wrong and possibly why. The current solution doesn't feel too bad though.
Fixes#1097.
The rendergl::render_scene() function is being called more often than
it needs to be, sometimes before the renderer has finished. This
could result in PNG images that are drawn before the frame trees set
in SetIds is rendered.
This should fix images produced by the -o flag.
The gl2::read_pixels call was asking for pixel data in RGB8 but was then telling the PNG encoder that the data was RGBA8. The value was originally set correctly, but was changed when support was added for drawing transparent PNGs.
We could instead adjust the gl2::read_pixels call to return RGBA8 so we can write transparent screenshots, but I'm not sure if there's a use case for that.
Constellation blocks on SetId by sending a Port through the compositor channel and waits for a response. If the compositor is in the process of shutting down, it will not look in the queue again. The compositor requires the constellation to be shut down first, so it sends a message to shut down and blocks until the constellation finishes, deadlocking.
Only very short lived executions would've been likely to see this deadlock.
_It is technically still possible to trigger a SetId message between when the compositor finishes running and when the constellation shuts down, but the window for exposure is greatly reduced. I've only seen it with "-o" so far._
Constellation blocks on SetId by sending a Port through the compositor
channel and waits for a response. If the compositor is in the process of
shutting down, it will not look in the queue again. The compositor
requires the constellation to be shut down first, so it sends a message
to shut down and blocks until the constellation finishes, deadlocking.
Only very short lived executions would've been likely to see this deadlock.
Moving another window on top of servo window, or switching screen would result in a blank window until the app was resized. This was due to a missing glfw callback.
Fixes#941.
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
r? @kmcallister
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
Fixes#222.
Implements 'text-align' inheritance for inline elements. The text alignment code has been changed a couple of times since the ticket was originally opened and was improved to inherit the text-align property from from an ancestor element. This addressed the issue, so long as no inline elements had a text-align property defined. Both Firefox and Chromium ignore any text-align properties attached to inline elements, but none of the specs are explicit about ignoring the property or inheriting only from non-inline elements:
http://www.w3.org/TR/CSS2/visuren.html#inline-formattinghttp://www.w3.org/TR/CSS2/text.html#propdef-text-align
This is my first stab at writing any code that touches the DOM node tree. Based on a few observations, I made the assumption that the `self.base.node` of a InlineFlow always corresponds to a BlockFlow-based node, no matter how deep inline DOM elements are nested; there was no obvious way to traverse Flow-traited objects directly and I'm not sure if it's possible to get from a FlowData struct back to a non-child {Block,Inline}Flow (probably intentionally).
I could've kept traversing the node tree directly, checking against each node style to ensure it didn't have an inline display property, but I could not create a scenario where the `base.node` was ever an inline. It also feels like a code smell to be walking up the tree at all, especially for stylesheet properties. Feels like it should eventually be handled in style::properties directly as being conditional inherited?
Fix this warning:
```
servo/src/components/gfx/platform/macos/font_list.rs:6:4: 6:42 warning: unused import, #[warn(unused_imports)] on by default
servo/src/components/gfx/platform/macos/font_list.rs:6 use font_context::FontContextHandleMethods;
```
This fixes the computation of restyle damage on `color-change-text.html`, which can be seen with `RUST_LOG=servo::layout::layout_task`.
However we can't prune the layout traversals yet, because we don't reuse `Flow` objects between reflows, so we have no old values to fall back to.
I think this used to work because `FlowContexts` (as they were called then) were stored in a DOM node's `LayoutData` and reused. But it's possible that it never really worked, and my testing when I landed the restyle damage code was insufficient (I didn't understand the layout code nearly as well back then).
r? @pcwalton
We don't reuse Flow objects between reflows, so we have no old values to fall
back to.
I think this used to work because FlowContexts (as they were called then) were
stored in a DOM node's LayoutData and reused. But it's possible that it never
really worked, and my testing when I landed the restyle damage code was
insufficient (I didn't understand the layout code nearly as well back then).
Instead we do selector matching again, then diff the style structs to set the
"restyle damage" bits which are used to prune reflow traversals.
Also don't force a reflow when timers finish, because individual DOM methods
should already take care of that.
