servo / webrender

A GPU-based renderer for the web

WebRender

WebRender is a GPU-based 2D rendering engine written in Rust. Firefox, the research web browser Servo, and other GUI frameworks draw with it. It currently uses the OpenGL API internally.

Note that the canonical home for this code is in gfx/wr folder of the mozilla-central repository at https://hg.mozilla.org/mozilla-central. The Github repository at https://github.com/servo/webrender should be considered a downstream mirror, although it contains additional metadata (such as Github wiki pages) that do not exist in mozilla-central. Pull requests against the Github repository are still being accepted, although once reviewed, they will be landed on mozilla-central first and then mirrored back. If you are familiar with the mozilla-central contribution workflow, filing bugs in Bugzilla and submitting patches there would be preferred.

Update as a Dependency

After updating shaders in WebRender, go to servo and:

• Go to the servo directory and do ./mach update-cargo -p webrender
• Create a pull request to servo

Use WebRender with Servo

To use a local copy of WebRender with servo, go to your servo build directory and:

• Edit Cargo.toml
• Add at the end of the file:

[patch."https://github.com/servo/webrender"]
"webrender" = { path = "<path>/webrender" }
"webrender_api" = { path = "<path>/webrender_api" }

where <path> is the path to your local copy of WebRender.

• Build as normal

Documentation

The Wiki has a few pages describing the internals and conventions of WebRender.

Testing

Tests run using OSMesa to get consistent rendering across platforms.

Still there may be differences depending on font libraries on your system, for example.

See this gist for how to make the text tests useful in Fedora, for example.

webrender's Issues

Blurry box shadows shouldn't be linear gradients

Instead they should be the integral of the Gaussian function.

reftest failures metabug

This has a list of the remaining reftest failures, and any details on what needs to be fixed.

Add zoom support

During a transition on opacity, pixel ratio is wrong

In the following example, when the transition starts, the text is scaled up. It doesn't appear to happen with a pixel ratio of 1, so I think it's specific to retina displays.

<style>

  div {
    margin: 100px;
    width: 200px;
    height: 200px;
    background: red;
    transition: opacity 1s linear;
  }

  div:hover {
    opacity: 0.5;
  }

</style>

<div>
  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</div>

Serialize displaylists from Servo to use as benchmarks/testcases

Currently measuring the performance impact of a change requires one to recompile servo and then run testcases with -w and scroll/do things. However, such tests don't produce consistent results, so it's hard to compare things.

We should add some infrastructure to Servo that lets us dump display lists to a file, and then add a bench/test harness to webrender that can read these files and measure performance (similar to what we do for clipping.

Use OpenGL Texture Arrays to improve batching

A very common reason for batch breaking is switching textures. This could be mitigated by improved texture atlas allocation algorithms, but they won't fully solve the problem. But the OpenGL 3.0 texture array feature will.

To do this we'll need some way to conditionally opt-in to its use in the shader when GL 3.0 support is present.

Add WebGL support

This is a meta-issue to discuss possible WebGL implementations with WebRender.

The first idea I had was keeping the WebGL task as-is, with the context sharing resources with the WebGL context, but that could be racy (that could be manually fixed though) as well as non-performant.

Another idea was to keep the same approach as now, but sending NativeSurfaces to WebRender. The WebRender context would re-bind the surface to a texture, and paint using that texture. It seems to me that it will work, avoiding the roundrip to main memory (I think that at least in GLX the texture will get the contents of the surface, and probably in other platforms too).

Glenn also suggested using the WebGL task as a command proxy, and do all the paint work in WebRender, avoiding any resource sharing to avoid using context sharing (which is an uncommon code path). In my opinion this won't work out well, since it also adds a lot of complexity, since WebRender would be responsible of keeping each WebGL context state separately (that includes a lot of non-trivial state such as viewport, etc.), and restoring the WebRender state, wich will be a considerable overhead.

That got me to think though, that the latter approach, combined with resource sharing could be the best option: Sharing resources between the contexts, using the WebGL task as a proxy (or even taking rid of it), but keeping the contexts in WebRender, and only executing gl commands when required.

Since I probably didn't explain myself very well, this would be an sketch of the proposed implementation:

• When a WebGL context is (trying to be) created, the WebGL paint task requests WebRender to create a context.
• WebRender creates a new gl context, sharing resources with the main context, associates it with an unique id and returns that id (or the error, if that's the case) to the WebGL task.
• The WebGL task just serializes the gl commands received from script in a form like (context_id, command).
• WebRender, before painting, takes that commands, sorts them by context id (to minimize context switching), and applies them to the given context. Note that there are special commands that need a reply from our side, like creating resources. When they arrive we could either do nothing until the next paint, when it will be processed, or flush the command buffer executing all the previous commands. The former is arguably simpler, but will make creating resources really slow, so I'd go for flushing the command buffer.
• WebRender does the actual paint, using the shared texture id's from the contexts.

I think this approach will be at least as performant as any other multithreaded approach, since most (if not all) the OpenGL implementations are single threaded, and this approach minimizes context switching, and prevents any kind of races that could be between WebRender and WebGL.

Note that the WebGL contexts should draw to a texture, but that's already done in the current implementation.

Also the WebGL task would be kind of naive with this scheme, so we could get rid of it easily I think.

I'd want to get some feedback or other ideas about this, and I could try to prototype it in the following weeks.

cc: @mrobinson @pcwalton @glennw

moving cursor over a loading iframe crashes Servo

STR:

<style>
  html, body {
    margin: 0;
    width: 100%;
    height: 100%;
  }
  iframe {
    display: block;
    width: 100%;
    height: 100%;
    border: 0;
  }
</style>
<iframe src="https://news.ycombinator.com/"></iframe>

While the page is loading (right after the window shows up), move the mouse over the window.

thread 'ScriptThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:330
stack backtrace:
   1:        0x1062f92d8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x1062fb4cf - panicking::default_handler::_<closure>::closure.41800
   3:        0x1062faf4f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x1062e60d4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x1062e657e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x1062f88f7 - rust_begin_unwind
   7:        0x10631fe60 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x10632015c - panicking::panic::h4d53392809a8cd58imK
   9:        0x1047342f2 - option::Option<T>::unwrap::h8177679629538280872
  10:        0x1045fef64 - script_thread::ScriptThread::root_page::hb226a8af91220ecdxwg
  11:        0x104738837 - script_thread::ScriptThread::handle_event::hdf5063ecbd91c0f9Czh
  12:        0x104765771 - script_thread::ScriptThread::handle_msg_from_constellation::h50ec7f86099ab034uIg
  13:        0x104764141 - script_thread::ScriptThread::handle_msgs::_<closure>::closure.172677
  14:        0x104763d62 - script_thread::ScriptThread::profile_event::h14477634762309725791
  15:        0x1047369ef - script_thread::ScriptThread::handle_msgs::h5d20ec0b7da30e42vxg
  16:        0x1046dfdc0 - script_thread::ScriptThread::start::h069c0d774b92fbe0lxg
  17:        0x1046dfd74 - script_thread::ScriptThread.ScriptThreadFactory::create::_<closure>::_<closure>::closure.171404
  18:        0x1046dfae0 - mem::ProfilerChan::run_with_memory_reporting::h2610061323499862213
  19:        0x1046c9c5f - script_thread::ScriptThread.ScriptThreadFactory::create::_<closure>::closure.170784
  20:        0x1046c9037 - util::thread::spawn_named_with_send_on_failure::_<closure>::closure.170771
  21:        0x1046c8a23 - std::thread::Builder::spawn::_<closure>::_<closure>::closure.170760
  22:        0x1046c8998 - sys_common::unwind::try::try_fn::h9419768829949667197
  23:        0x1062f8718 - __rust_try
  24:        0x1062f55ce - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  25:        0x1046c88d5 - sys_common::unwind::try::h15585938672162292927
  26:        0x1046c870e - std::thread::Builder::spawn::_<closure>::closure.170757
  27:        0x1046c9257 - boxed::F.FnBox<A>::call_box::h1689917281937953796
  28:        0x1062fa5ed - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  29:     0x7fff94c9599c - _pthread_body
  30:     0x7fff94c95919 - _pthread_start
thread 'Constellation' panicked at 'unable to find pipeline - this is a bug', ../src/libcore/option.rs:298
stack backtrace:
thread 'LayoutThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("MPSC send failed") }) }', ../src/libcore/result.rs:688
thread 'PaintThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("recursive IPC channel use during serialization") }) }', ../src/libcore/result.rs:688
   1:        0x1062f92d8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x1062fb4cf - panicking::default_handler::_<closure>::closure.41800
   3:        0x1062faf4f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x1062e60d4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x1062e657e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x1062f88f7 - rust_begin_unwind
   7:        0x10631fe60 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1036f731f - option::Option<T>::expect::h5339844227311931841
   9:        0x1037c5488 - constellation::Constellation<LTF, STF>::handle_failure_msg::h12046843456072119420
  10:        0x10367b301 - constellation::Constellation<LTF, STF>::handle_request::h15666559289675337404
  11:        0x103677d3c - constellation::Constellation<LTF, STF>::run::h3172571108249641926
  12:        0x10365b9e3 - export::compositing::constellation::Constellation<LTF, STF>::start::_<closure>::closure.24011
  13:        0x103659823 - std::thread::Builder::spawn::_<closure>::_<closure>::closure.24000
  14:        0x103659798 - sys_common::unwind::try::try_fn::h3515637966895896247
  15:        0x1062f8718 - __rust_try
  16:        0x1062f55ce - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  17:        0x1036596d5 - sys_common::unwind::try::h11623311639750873733
  18:        0x10365950e - std::thread::Builder::spawn::_<closure>::closure.23977
  19:        0x10365bca7 - boxed::F.FnBox<A>::call_box::h8828800509819653060
  20:        0x1062fa5ed - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  21:     0x7fff94c9599c - _pthread_body
  22:     0x7fff94c95919 - _pthread_start
stack backtrace:
   1:        0x1062f92d8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x1062fb4cf - panicking::default_handler::_<closure>::closure.41800
   3:        0x1062faf4f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x1062e60d4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x1062e657e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x1062f88f7 - rust_begin_unwind
   7:        0x10631fe60 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1039e7de6 - result::Result<T, E>::unwrap::h13669876520401285798
   9:        0x103c219ab - layout_thread::LayoutThread::exit_now::h0506a6bb12b6796b8Yq
  10:        0x103beaba0 - layout_thread::LayoutThread::handle_request_helper::hc8c44cd9203fe4dd3Oq
  11:        0x103bc0f9b - layout_thread::LayoutThread::handle_request::h2ace98cf47d88468sJq
  12:        0x103b8d13a - layout_thread::LayoutThread::start::h2abcb552cbf69a3dHHq
  13:        0x103b8cf87 - layout_thread::LayoutThread.LayoutThreadFactory::create::_<closure>::_<closure>::closure.55183
  14:        0x103b87183 - mem::ProfilerChan::run_with_memory_reporting::h15726168540943441063
  15:        0x103b50fdd - layout_thread::LayoutThread.LayoutThreadFactory::create::_<closure>::closure.53457
  16:        0x103b50357 - util::thread::spawn_named_with_send_on_failure::_<closure>::closure.53428
  17:        0x103b4fd43 - std::thread::Builder::spawn::_<closure>::_<closure>::closure.53417
  18:        0x103b4fcb8 - sys_common::unwind::try::try_fn::h5284159491821017053
  19:        0x1062f8718 - __rust_try
  20:        0x1062f55ce - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  21:        0x103b4fbf5 - sys_common::unwind::try::h13556685622416969616
  22:        0x103b4fa2e - std::thread::Builder::spawn::_<closure>::closure.53394
  23:        0x103b505b7 - boxed::F.FnBox<A>::call_box::h11784976529355248574
  24:        0x1062fa5ed - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  25:     0x7fff94c9599c - _pthread_body
  26:     0x7fff94c95919 - _pthread_start
stack backtrace:
   1:        0x1062f92d8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x1062fb4cf - panicking::default_handler::_<closure>::closure.41800
   3:        0x1062faf4f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x1062e60d4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x1062e657e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x1062f88f7 - rust_begin_unwind
   7:        0x10631fe60 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x104b024f6 - result::Result<T, E>::unwrap::h16971998360882155653
   9:        0x104b896de - gfx::paint_thread::PaintThread<C>::create::_<closure>::closure.33526
  10:        0x104b88917 - util::thread::spawn_named_with_send_on_failure::_<closure>::closure.33497
  11:        0x104b88303 - std::thread::Builder::spawn::_<closure>::_<closure>::closure.33486
  12:        0x104b88278 - sys_common::unwind::try::try_fn::h962043809951869491
  13:        0x1062f8718 - __rust_try
  14:        0x1062f55ce - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  15:        0x104b881b5 - sys_common::unwind::try::h9372886371861194604
  16:        0x104b87fee - std::thread::Builder::spawn::_<closure>::closure.33463
  17:        0x104b88b77 - boxed::F.FnBox<A>::call_box::h3399964151574302148
  18:        0x1062fa5ed - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  19:     0x7fff94c9599c - _pthread_body
  20:     0x7fff94c95919 - _pthread_start

Crash while loading firefox.com: webrender/src/batch_builder.rs:149

It used to work.

thread '<unnamed>' panicked at 'assertion failed: clipped_pos_rect.size.width.fract() == 0.0', /Users/paul/git/servo-webrender/../webrender/src/batch_builder.rs:149
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x1072ed5c4 - sys_common::unwind::begin_unwind::h13565596160845807443
   6:        0x1072f0244 - batch_builder::BatchBuilder<'a>::add_complex_clipped_rectangle::hebf281d23e314c0817a
   7:        0x107337d8b - node_compiler::AABBTreeNode.NodeCompiler::compile::hf0a692f303e5ee6eA5n
   8:        0x107336ebf - F.FnBox::call_box::h8589827017861732960
   9:        0x10761d650 - sys_common::unwind::try::try_fn::h12873994005467651312
  10:        0x107f9dff8 - __rust_try
  11:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  12:        0x10761ffc2 - boxed::F.FnBox<A>::call_box::h14464300662002536950
  13:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  14:     0x7fff9b6a799c - _pthread_body
  15:     0x7fff9b6a7919 - _pthread_start
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x107625e71 - Scope<'pool, 'scope>::join_all::h2ee880d8cd87cb45aga
   9:        0x10732c6a4 - frame::Frame::build::h2b3f03710f0c3e00snk
  10:        0x10737f575 - render_backend::RenderBackend::render::hb46ccf1c5ac5f41bgVo
  11:        0x10734b342 - render_backend::RenderBackend::run::hef23f9f4d0176fdarLo
  12:        0x10739e9b4 - sys_common::unwind::try::try_fn::h4037959654079087717
  13:        0x107f9dff8 - __rust_try
  14:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  15:        0x10739fafa - boxed::F.FnBox<A>::call_box::h4080903807828173708
  16:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  17:     0x7fff9b6a799c - _pthread_body
  18:     0x7fff9b6a7919 - _pthread_start
thread 'LayoutThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("recursive IPC channel use during serialization") }) }', ../src/libcore/result.rs:688
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x107789549 - api::RenderApi::add_display_list::h9c8dff3db95ad97bJHb
   9:        0x106a33da6 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  10:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  11:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  12:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  13:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  14:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  15:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  16:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  17:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  18:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  19:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  20:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  21:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  22:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  23:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  24:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  25:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  26:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  27:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  28:        0x106a8f0bf - layout_thread::LayoutThread::perform_post_main_layout_passes::h2432abf606c57c67Ear
  29:        0x106a04db4 - layout_thread::LayoutThread::perform_post_style_recalc_layout_passes::h6a718355ed85f0c147q
  30:        0x1069d73ae - layout_thread::LayoutThread::handle_request::hc16ed0d4edae377fhmq
  31:        0x10699f8ca - sys_common::unwind::try::try_fn::h10583997351341377314
  32:        0x107f9dff8 - __rust_try
  33:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  34:        0x1069a084a - boxed::F.FnBox<A>::call_box::h7559661375126348099
  35:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  36:     0x7fff9b6a799c - _pthread_body
  37:     0x7fff9b6a7919 - _pthread_start
thread 'PaintThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
stack backtrace:
thread 'LayoutWorker worker 2/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
thread 'LayoutWorker worker 3/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
thread 'LayoutWorker worker 1/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
thread 'Constellation' panicked at 'unable to find pipeline - this is a bug', ../src/libcore/option.rs:298
   2:        0x107fa0daf - panicking::default_handler::_<closurethread 'PaintThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("recursive IPC channel use during serialization") }) }', ../src/libcore/result.rs:688
>::closure.41800
thread 'ScriptThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:688
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1071cbfcb - paint_thread::PaintThread<C>::start::h8891479371392591342
   9:        0x1071bef22 - sys_common::unwind::try::try_fn::h12919057137521718273
  10:        0x107f9dff8 - __rust_try
thread 'LayoutThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("recursive IPC channel use during serialization") }) }', ../src/libcore/result.rs:688
  11:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  12:        0x1071bfa0a - boxed::F.FnBox<A>::call_box::h15390661390261453747
  13:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  14:     0x7fff9b6a799c - _pthread_body
  15:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
thread 'thread 'PaintWorker' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
thread 'PaintWorker' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
PaintWorker' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1069c4eec - sys_common::unwind::try::try_fn::h17384109164497557634
   9:        0x107f9dff8 - __rust_try
  10:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  11:        0x1069c5e77 - boxed::F.FnBox<A>::call_box::h2582450649537092597
  12:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  13:     0x7fff9b6a799c - _pthread_body
  14:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1069c4eec - sys_common::unwind::try::try_fn::h17384109164497557634
   9:        0x107f9dff8 - __rust_try
  10:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  11:        0x1069c5e77 - boxed::F.FnBox<A>::call_box::h2582450649537092597
  12:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  13:     0x7fff9b6a799c - _pthread_body
  14:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1069c4eec - sys_common::unwind::try::try_fn::h17384109164497557634
   9:        0x107f9dff8 - __rust_try
  10:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  11:        0x1069c5e77 - boxed::F.FnBox<A>::call_box::h2582450649537092597
  12:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  13:     0x7fff9b6a799c - _pthread_body
  14:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x106896017 - constellation::Constellation<LTF, STF>::handle_failure_msg::h6719814148374464005
   9:        0x106814c9e - constellation::Constellation<LTF, STF>::handle_request::h12398965808278059948
  10:        0x1067ffbe7 - export::compositing::constellation::Constellation<LTF, STF>::start::_<closure>::closure.23898
  11:        0x1067ff489 - sys_common::unwind::try::try_fn::h7098318269982728237
  12:        0x107f9dff8 - __rust_try
  13:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  14:        0x1068012fa - boxed::F.FnBox<A>::call_box::h17544099623018493435
  15:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  16:     0x7fff9b6a799c - _pthread_body
  17:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x1071bf4fb - sys_common::unwind::try::try_fn::h12919057137521718273
   9:        0x107f9dff8 - __rust_try
  10:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  11:        0x1071bfa0a - boxed::F.FnBox<A>::call_box::h15390661390261453747
  12:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  13:     0x7fff9b6a799c - _pthread_body
  14:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x106e90fed - dom::node::OpaqueStyleAndLayoutData::dispose::he573f803fd4d198fbzZ
   9:        0x106e911c7 - dom::node::Node::teardown::h80d4b050be947b38aKZ
  10:        0x106e912c9 - dom::node::Node::teardown::h80d4b050be947b38aKZ
  11:        0x106f44b1b - dom::window::Window::clear_js_runtime::h8c654f127cca3d7diic
  12:        0x106fd6ebd - script_thread::shut_down_layout::h43b108923ec0ed98jIi
  13:        0x106fba187 - script_thread::ScriptThread::handle_msgs::_<closure>::closure.169574
  14:        0x106fa2ebf - script_thread::ScriptThread::handle_msgs::h42902ccbeb26d4284nh
  15:        0x106f6a257 - sys_common::unwind::try::try_fn::h6700430166590279951
  16:        0x107f9dff8 - __rust_try
  17:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  18:        0x106f6bce1 - boxed::F.FnBox<A>::call_box::h4377540654281972257
  19:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  20:     0x7fff9b6a799c - _pthread_body
  21:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
thread 'ScriptThread PipelineId { namespace_id: PipelineNamespaceId(0), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:688
   8:        0x107789549 - api::RenderApi::add_display_list::h9c8dff3db95ad97bJHb
   9:        0x106a33da6 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  10:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  11:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  12:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  13:        0x106aa35f3 - webrender_helpers::DisplayItem.WebRenderDisplayItemConverter::convert_to_webrender::h8049ad97dde53199nhx
  14:        0x106aa226f - webrender_helpers::Box<DisplayList>.WebRenderDisplayListConverter::convert_to_webrender::hf7e8dec913d33989nfx
  15:        0x106a33d57 - webrender_helpers::StackingContext.WebRenderStackingContextConverter::convert_to_webrender::hf65854b25150004bOdx
  16:        0x106a8f0bf - layout_thread::LayoutThread::perform_post_main_layout_passes::h2432abf606c57c67Ear
  17:        0x106a04db4 - layout_thread::LayoutThread::perform_post_style_recalc_layout_passes::h6a718355ed85f0c147q
  18:        0x106a0b2ba - layout_thread::LayoutThread::handle_reflow::hb77a0d746fab5f65COq
  19:        0x1069f24ae - layout_thread::LayoutThread::handle_request_helper::hdfa3c6c5e15c3dfbSrq
  20:        0x1069d7431 - layout_thread::LayoutThread::handle_request::hc16ed0d4edae377fhmq
  21:        0x10699f8ca - sys_common::unwind::try::try_fn::h10583997351341377314
  22:        0x107f9dff8 - __rust_try
  23:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  24:        0x1069a084a - boxed::F.FnBox<A>::call_box::h7559661375126348099
  25:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  26:     0x7fff9b6a799c - _pthread_body
  27:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
thread 'LayoutWorker worker 1/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:thread 'thread 'LayoutWorker worker 2/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
ScriptThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(0) }' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', ../src/libcore/result.rs:688
688
thread 'LayoutWorker worker 3/3' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', ../src/libcore/result.rs:688
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x10741ffb7 - paint_thread::WorkerThread::main::h1f33011f9833d7f4zco
   9:        0x10741e02b - sys_common::unwind::try::try_fn::h8834067971183654828
  10:        0x107f9dff8 - __rust_try
  11:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  12:        0x10741e5c6 - boxed::F.FnBox<A>::call_box::h11412307701203464889
  13:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  14:     0x7fff9b6a799c - _pthread_body
  15:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x10741ffb7 - paint_thread::WorkerThread::main::h1f33011f9833d7f4zco
   9:        0x10741e02b - sys_common::unwind::try::try_fn::h8834067971183654828
  10:        0x107f9dff8 - __rust_try
  11:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  12:        0x10741e5c6 - boxed::F.FnBox<A>::call_box::h11412307701203464889
  13:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  14:     0x7fff9b6a799c - _pthread_body
  15:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x10741ffb7 - paint_thread::WorkerThread::main::h1f33011f9833d7f4zco
   9:        0x10741e02b - sys_common::unwind::try::try_fn::h8834067971183654828
  10:        0x107f9dff8 - __rust_try
  11:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  12:        0x10741e5c6 - boxed::F.FnBox<A>::call_box::h11412307701203464889
  13:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  14:     0x7fff9b6a799c - _pthread_body
  15:     0x7fff9b6a7919 - _pthread_start
stack backtrace:
   1:        0x107f9ebb8 - sys::backtrace::tracing::imp::write::hdd549f07f7745d62xZt
   2:        0x107fa0daf - panicking::default_handler::_<closure>::closure.41800
   3:        0x107fa082f - panicking::default_handler::haa11ce011d688073GWx
   4:        0x107f8b9b4 - sys_common::unwind::begin_unwind_inner::h5fdd923b078bc2aaz2s
   5:        0x107f8be5e - sys_common::unwind::begin_unwind_fmt::hca18532ec345b882F1s
   6:        0x107f9e1d7 - rust_begin_unwind
   7:        0x107fc5740 - panicking::panic_fmt::he5f9c513e9167673LnK
   8:        0x106e90fed - dom::node::OpaqueStyleAndLayoutData::dispose::he573f803fd4d198fbzZ
   9:        0x106b3b808 - dom..node..Node::drop.135924::h0738048cd066ae62
  10:        0x106b3b73a - dom::bindings::codegen::Bindings::CommentBinding::_finalize::h5a14a82b9eb2daf5OmD
  11:        0x107e4f15e - _ZN2js2gc5Arena8finalizeI8JSObjectEEmPNS_6FreeOpENS0_9AllocKindEm
  12:        0x107e08704 - _ZL14FinalizeArenasPN2js6FreeOpEPPNS_2gc11ArenaHeaderERNS2_15SortedArenaListENS2_9AllocKindERNS_11SliceBudgetENS2_10ArenaLists14KeepArenasEnumE
  13:        0x107e0be85 - _ZN2js2gc10ArenaLists30queueForegroundObjectsForSweepEPNS_6FreeOpE
  14:        0x107e11c93 - _ZN2js2gc9GCRuntime22beginSweepingZoneGroupEv
  15:        0x107e128f6 - _ZN2js2gc9GCRuntime15beginSweepPhaseEb
  16:        0x107e1501c - _ZN2js2gc9GCRuntime23incrementalCollectSliceERNS_11SliceBudgetEN2JS8gcreason6ReasonE
  17:        0x107e15724 - _ZN2js2gc9GCRuntime7gcCycleEbRNS_11SliceBudgetEN2JS8gcreason6ReasonE
  18:        0x107e15bfe - _ZN2js2gc9GCRuntime7collectEbNS_11SliceBudgetEN2JS8gcreason6ReasonE
  19:        0x107dc6afa - _ZN2js14DestroyContextEP9JSContextNS_18DestroyContextModeE
  20:        0x1079d60d1 - rust::Runtime.Drop::drop::he9a44b687b1d0465mKi
  21:        0x106f6fca8 - script_thread..ScriptThread::drop.167774::h387993027f24bb71
  22:        0x106f6b4e6 - sys_common::unwind::try::try_fn::h6700430166590279951
  23:        0x107f9dff8 - __rust_try
  24:        0x107f9aeae - sys_common::unwind::try::inner_try::h3da6140ab038e3437Ys
  25:        0x106f6bce1 - boxed::F.FnBox<A>::call_box::h4377540654281972257
  26:        0x107f9fecd - sys::thread::Thread::new::thread_start::hf2e9bf34aeeb6fa0acx
  27:     0x7fff9b6a799c - _pthread_body
  28:     0x7fff9b6a7919 - _pthread_start
thread panicked while panicking. aborting.stack backtrace:

iframe are not sensitive to mouse events

For example, hovering a link or clicking on a link does nothing.

Some box shadows aren't drawn correctly.

Loading http://thany.nl/apps/BoxShadows/ with WR shows several incorrect box-shadow renderings.

background image breaks scrolling

background-image: url(…) with a large background size makes the scrolling area larger.

In the following example, it possible to scroll down and right. Changing the background size change how much we can scroll.

<style>
  body {
    margin: 0;
    background: red;
    width: 100%;
    height: 100%;
  }

  div {
    background-image: url("data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=");
    background-repeat: no-repeat;
    background-size: 200px 200px;
    position: absolute;
    height: 30px;
    width: 30px;
    border: 2px solid black;
    bottom: 0;
    right: 0;
  }



</style>

<div></div>

border_radius_shorthand_a.html assertion failure

thread '' panicked at 'Couldn't find border radius 200px in raster-to-image map!', servo_gfx/webrender/src/render_backend.rs:2934

border radius >= 32 px not working

<!DOCTYPE html>
<html>
  <head>
    <style type="text/css">
      .box {
        background-color: red;
        width: 80px;
        height: 80px;
        margin: 16px;
      }
    </style>
  </head>
  <body>
    <div class="box" style="border-radius: 16px;"></div>
    <div class="box" style="border-radius: 24px;"></div>
    <div class="box" style="border-radius: 31px;"></div>
    <div class="box" style="border-radius: 32px;"></div>
    <div class="box" style="border-radius: 64px;"></div>
  </body>
</html>

Consider batching render targets for distinct composite operations together

For example, if we have two elements with opacity: 0.9 (or the corresponding filter property, or a mix-blend-mode, etc.), and their combined area is less than the maximum texture size, then we can batch them into one large framebuffer and then blit the contents of that framebuffer onto the back buffer all in one go.

In the optimum case, this should reduce the number of batches from one batch per composited element to one batch per level of nesting depth of composited elements.

Some documentation of the chromium implementation.

The blinks devs already try to use the gpu for drawing, see here some documentation : https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
But their implementation seems less ambitions ;)
Sorry if I have said something of stupid.

Implement navigation support.

Antialias border corners

They need to be antialiased. This is basically just a question of modifying the fragment shader.

Blocking issues before merging to master.

NOTE: Not all of these need to be blockers - but this is a list of items that I'm aware of which could be blockers.

• Some of the newly enabled reftests have introduced more pass / fail differences (transforms, filters) - investigate these.
• Pixel / texel snapping seems wrong in some cases (maybe only on Linux).
• Fix image_rendering_auto reftest (should be fixed by above item).
• Anti aliasing solution.
• Render target effects + transforms not supported yet.
• Allow texture cache to clear items.
• Instancing / GPU clipping.
• Decompose gradients to rectangles.
• Support window resizing.
• Reftests broken by the gradient change: https://github.com/glennw/webrender/issues/167
• https://github.com/glennw/webrender/issues/168
• Blend mode issue with text: https://github.com/glennw/webrender/issues/166
• https://github.com/glennw/webrender/issues/160
• https://github.com/glennw/webrender/issues/157
• Box shadow gaps: https://github.com/glennw/webrender/issues/156

Also useful but not blocking:

• Get changes to WPT test scripts etc made to enable different test expectations.
• Integrate with new DL generation code (when it lands).
• Render targets that are scroll roots (probably) not supported yet [not working in normal servo either]

Poor batching on GitHub

http://github.com/servo/servo has 132 draw calls. Something is going wrong here.

Make a developers call ?

From what I understund, webrender play a major performance and efficiency role on servo but it has only 2 developpers !
I think that because webrender is a priority,you should do a developpers call on the servo github,it's Just an idea from Just a mozilla fan so maybe I say something of stupid.

Creating VBOs spends an inordinate amount of time in round()

Like, at least 20% of the time spent in rendering is spent in roundf(), probably more.

Do we really need to round when converting floating point to fixed point that way?

background image duplicated with border-radius + background-size:cover

webrender only issue:

<style>
  div {
    background-size: cover;
    border-radius: 10px;
    width: 100px;
    height: 100px;
    border:0.5px solid red;
    background-image: url(http://www.google.com/favicon.ico);
  }
</style>
<div></div>

Consider some form of DLBI for batch retention between paints

If we could cache the batches on a per-bunch-of-display-item basis between paints somehow, then we could potentially get large wins when only small parts of the page change (say, hovering over links and buttons).

This would be different from traditional DLBI because the idea would be to cache VBOs (or parts of VBOs) rather than being spatial, though of course it could be combined with a form of spatial invalidation later (though given that we aren't ROP-bound, the latter seems unlikely to be that helpful).

We could reuse parts of my DLBI patch to Servo to compare and diff display items if we want to proceed down this path.

Make use of openCL ?

I think there is possible use case of openCL on webrender.

Gimp 2.10 for exemple will use for render images : http://fr.slideshare.net/mobile/lgworld/implementing-opencl-support-in-gegl-and-gimp

Even libreoffice now use opencl :
http://developer.amd.com/community/blog/2015/07/15/collaboration-and-open-source-at-amd-libreoffice/
And it's a contribution from AMD, so I think that if there is use case of openCL on servo/webrender you should ask to AMD to help you.

Also amd will in the near future open source it's openCL 2.0 implementation so all opensource drivers will probably benefit of this.

content is cropped when box-shadow is drawn inside a overflow:hidden element

<body style="margin:0">
  <div style="background: blue; width: 100%; height: 100%; position: absolute; overflow: hidden;">
    <div style="background: red; height: 40px; position: absolute; width: 40px; box-shadow: 10px 10px 10px black;"></div>
  </div>
</body>

Support arbitrary clip/transform stacks

The idea here is to have a compressed matrix/transform palette and clip out in the fragment shader. This is somewhat slow in that it could have a lot of unnecessary FS invocations, but it's on-GPU instead of on-CPU and doesn't mandate batch breaks unlike stencil-based solutions, and that seems like a win. The common cases are handled in the VS, so this should only happen in uncommon situations.

gw: pcwalton: my tentative plan was to add support to the shader to handle clips as either a simple rect (as now) or a compressed set of 4 clip plans with arbitrary transform. I haven't checked that this idea will actually work yet :) But yes, you're right - if it works, that could handle gradients.
gw: pcwalton: Yes, a palette like the rects. I think they could be compressed a lot in the uniforms too - since there is only one normal you need (two planes have the same normal, the other two are perpendicular). I think we could just specify one normal and 4 d values perhaps or something like that...

transformed iframe not properly cropped

webrender vs. regular servo:

<style>
  iframe {
    border: 3px solid red;
    transform: rotate(45deg);
  }
</style>
<iframe src="http://paulrouget.com"></iframe>

Look at GLyphy to render glyphs on GPU?

(Not quite sure how to contact you, so here goes:)

Behdad Esfahbod wrote this little lib here: https://github.com/behdad/glyphy

Maybe this fits your project better than FreeType?

GPU data transfer is slow on Intel HD Graphics 3000

I've got a MacBook Air (11-inch, Mid 2011) as a loaner laptop and I decided to take WebRender for a spin so we could try out lower-end GPUs. Happily, we don't seem to be GPU bound here. But I think the GPU-CPU transfer is slow, making compositing take 8ms or so in many cases. This is too slow for comfort.

Here's the heaviest stack trace:

  11 servo 2170.0  renderer::_$LT$impl$GT$::render::h41fdfb2e98ec730cYdc
  10 GLEngine 1805.0  glDrawElements_ACC_Exec
   9 GLEngine 1551.0  gleDoDrawDispatchCore
   8 AppleIntelHD3000GraphicsGLDriver 1516.0  gldUpdateDispatch
   7 libGPUSupport.dylib 1424.0  gpusLoadCurrentVertexArray
   6 AppleIntelHD3000GraphicsGLDriver 1416.0  glrUpdateBuffer
   5 AppleIntelHD3000GraphicsGLDriver 1403.0  SysResourceBufferManager::LoadSysBufferObject(GLDShareGroupRec*, GLDBufferRec*, unsigned long long)
   4 libGPUSupport.dylib 1361.0  gpusGetKernelVertexObjectAGPRef
   3 IOKit 1349.0  IOConnectCallMethod
   2 IOKit 1344.0  io_connect_method
   1 libsystem_kernel.dylib 1339.0  mach_msg
   0 libsystem_kernel.dylib 1337.0  mach_msg_trap

I don't know whether how well this is going to be fixable, but we could try using glMapBuffer perhaps?

can’t animate both opacity and transform

It works for background-color+transform or width+transform, but not opacity+transform.

<style>
  div {
    position: absolute;
    top: 10px;
    left: 10px;
    width: 100px;
    height: 100px;
    background: red;
    transition: all 2000ms linear;
  }

  div.foo {
    opacity: 0.5;
    transform: translateY(200px);
  }
</style>

<div></div>

<script>
  var div = document.querySelector('div');
  setTimeout(() => div.className = 'foo', 1000);
</script>

border radius is pixelated

<style>
  div {
    width: 200px;
    height: 20px;
    border-radius: 50%;
    background: red;
  }
</style>

<div></div>

Some Wikipedia articles spend a lot of time in the AABB tree

For some reason we spend a lot of time in:

aabbtree::_$LT$impl$GT$::find_best_node::ha90e540da0edbf0bkjd

on http://en.wikipedia.org/wiki/Spotted_hyena

iframe content is not transformed

webrender only:

<style>
  iframe {
    border: 3px solid red;
    transform: rotate(45deg);
  }
</style>
<iframe src="http://paulrouget.com"></iframe>

Culling can spend a long time resetting "node.is_visible" to false

Perhaps we should set node.is_visible to false only when needed based on the results from the previous frame?

sepia ref test has slightly different output

cc @pcwalton

assert!(item.node_index.is_none()) fails frequently

Using WebRender on https://developer.mozilla.org/en-US/docs/Web/CSS/filter (and other pages) causes that assertion to trigger. I'm not sure what this assertion is supposed to be doing.

Sample gaussian instead of calculating it

For gaussian blurs, we calculate the gaussian value for every fragment.

It might be better to create a single 1D texture which we sample and transform for calculating the gaussian.

(Not sure how this all works on the Rust side, filing as a placeholder)

Too many vertices with tiled backgrounds on large pages

Example page: https://miiverse.nintendo.net/guide/

This page creates 35,346 tilings of the background image, since we have a 12x12 background tiled to a layer of 1024x4931. Every time the root stacking context is updated, we recreate the tiles for the entire layer. This slows WebRender to a crawl, even with some optimizations I'm about to land.

The obvious way to fix this would be to only tile inside the screen rect. This would reduce the number of tilings to about 5,500. Is this compatible with the batch caching design?

Another possible approach is to break up large tiled images to a few medium-sized areas in the AABB tree, so that we can more aggressively cull outside the visible area.

Yet another way to fix this would be to pre-cache a few repeats of repeating backgrounds a bit to reduce the number of tiles that have to be drawn. I don't like this approach much because it wastes memory, increases load on the rasterizer, and it doesn't really solve the problem in the general case.

Last, we could have a special shader for large tiled backgrounds. This is a last resort, though, because it will either break our batching or complicate the quad shader.

switching from "visibility:hidden" to "visibility:visible", iframe size is wrong for a short period of time

It's hard to tell if it's a webrender-specific issue or not. Maybe non-webrender builds are not fast enough to show the problem.

While an iframe switch from visibility:hidden to visibility:visible (or display:none to display:block), for a very short period of time (one frame), the size of its content is wrong. The 3 following screenshots are 3 consecutive frames:

<style>
  iframe {
    display: block;
    border-width: 0;
    top: 0;
    left: 0;
    width: 100vw;
    height: 100vh;
    position: absolute;
  }
  iframe.s {
    visibility: hidden; /* or display: none */
  }
</style>

<iframe mozbrowser="true" src="http://firefox.com"></iframe>

<script>
  setInterval(() => document.querySelector("iframe").classList.toggle("s"), 500);
</script>

http://robert.ocallahan.org/ scrolls slowly either due to iframes or CPU load

WebRender reports its typical very fast timings (1-2 ms) on http://robert.ocallahan.org/ but scrolling is still slow. Servo goes into an endless loop of reflows, saturating most of the CPU on this site, but WebRender should still be fast. Unfortunately, it seems to be slow, even though the reported timings are fast.

I suspect that either (a) the iframes are hurting our FPS somehow; (b) the OS scheduler is penalizing WebRender for the bad behavior of layout.

Support scroll layers

Experiment with tessellation shaders for text runs and tiled backgrounds

We spend a lot of time—probably most of our time—building batches for text runs and tiled backgrounds, because those display items are common and have a lot of vertices. It would be nice if we had a way to dramatically reduce the number of vertices we have to build for each of those. OpenGL 4.0 tessellation shaders seem like a possible solution here, because tessellation shaders leverage the GPU's parallelism to construct multiple vertices for a single input patch.

A rough sketch of the idea—details are to be determined:

• If tessellation shader support is available, don't build quads for each glyph in a text run and tiling of an image in a tiled background. Instead, build a single patch for the text run or background's bounding box, and mark it with a special attribute value so that the tessellation shader knows it should subdivide it.
• In the Tessellation Control Shader, subdivide the bounding rect into the correct number of glyphs or image repeats.
• In the Tessellation Evaluation Shader:
  • For tiled images, simply adjust the vertex positions and texture coordinates appropriately so that the size of each quad is equal to the size of the image (except around the edges).
  • For text runs, what to do here is somewhat less clear. One potential approach would be the following: First, during rasterization, build a lookup table (LUT) texture that defines the metrics and uv coordinates for each rasterized glyph in the font. Next, supply a per-text-run LUT that specifies glyph IDs and advances for each glyph. In the TES, use the value of gl_TessCoord to index into the second LUT to get the glyph ID, and using that index into the first LUT to determine the glyph metrics. The major unknown here is how to efficiently provide the second LUT—the per-text-run LUT—to the TES.

Before embarking on this, it would be good to get some numbers to verify that we are indeed spending most of our time in tiled background and text run vertex construction on most pages.

Can't scroll iframes

Iframe content can't be scrolled:

<iframe src="http://paulrouget.com"></iframe>

inset shadow + border radius: crash

<style>

  .a {
    width: 400px;
    height: 400px;
    background-color: red;
  }

  .b {
    width: 300px;
    height: 20px;
    margin: 50px;
    border-radius: 1000px;
    box-shadow: inset 0 0 0 2px #0F0;
  }

</style>


<div class="a">
  <div class="b">
  </div>
</div>

box-shadow shape is wrong

The corners of the shadow is supposed to be shaped by the element border radius, not by its spread radius value.

<style>
  div {
    margin: 30px;
    width: 200px;
    height: 200px;
    background: #0F0;
    display: inline-block;
  }
</style>

<div style="box-shadow: 0 0 10px red"></div>
<div style="box-shadow: 0 0 20px red"></div>
<div style="box-shadow: 0 0 30px red"></div>
<div style="box-shadow: 0 0 40px red"></div>

add_border and friends need to pass clip_rect and use it.

Too much overdraw with large border radii

When drawing things like circles using border radii, we paint too many transparent pixels. We should tessellate a bit if there are going to be too many transparent pixels to paint.

Test case:

<!DOCTYPE html>
<style>
main {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}
.circle {
    border-radius: 50%;
    position: absolute;
    top: 50%;
    left: 50%;
}
.a {
    border: solid gray 3px;
}
.object {
    position: absolute;
    width: 100%;
    height: 100%;
}
</style>
<body>
<main>
<div id=object-a class=object></div>
<div id=object-b class=object></div>
</main>
<script>
var main = document.getElementsByTagName('main')[0];
function makeCircle(container, klass, radius) {
    var div = document.createElement('div');
    div.setAttribute('class', "circle " + klass);
    div.setAttribute('data-radius', radius);
    div.style.marginLeft = -(radius / 2) + 'px';
    div.style.marginTop = -(radius / 2) + 'px';
    div.style.width = radius + 'px';
    div.style.height = radius + 'px';
    container.appendChild(div);
}
function makeCircles(container) {
    for (var i = 0; i < 128; i++) {
        makeCircle(container, 'a', i * 16);
    }
}
var objectA = document.getElementById('object-a');
var objectB = document.getElementById('object-b');
makeCircles(objectA);
makeCircles(objectB);

var startTime = Date.now();
function updateObject(object, t) {
    var d = 200;
    var x = Math.sin(t) * d, y = Math.cos(t) * d;
    object.style.left = x + 'px';
    object.style.top = y + 'px';
}
function next() {
    var now = Date.now();
    var t = (now - startTime) / 1600;
    updateObject(objectA, t); 
    updateObject(objectB, t + 800); 
    setTimeout(next, 16);
}
next();

</script>

iframe border and background are not visible if transformed

<style>

  div {
    background: #F00;
    position: absolute;
    width: 100%;
    height: 100%;
    perspective: 0px;
    left: 0;
  }

  iframe {
    display: block;
    position: absolute;
    width: 100%;
    height: 100%;
    transform: translate3d(0px, 0px, 0px);

    /* Not visible: */
    background: #00F;
    border: 4px solid #0F0;

  }

</style>

<div>
  <iframe src="data:,XXX"></iframe>
</div>

Inspire from different game engine implementations ?

You say on the wiki that webrender is like à game engine, so why not watch and inspire from the source code of existing game engine ?
You could win a lot of time !

Here the godot engine : https://github.com/godotengine/godot
And the wiki for understunding : https://github.com/godotengine/godot/wiki

For the unreal engine : https://github.com/EpicGames/Signup (the code is not full free and need an account)

The ogre engine : http://www.ogre3d.org/

The love engine (2d only) : https://love2d.org/

Also a very interesting project, a game engine for HTML 5, the cube engine : https://github.com/Nurgak/Cube-engine

A list of others html5 game engine : https://html5gameengine.com/

A list of all standard game engine : https://en.m.wikipedia.org/wiki/List_of_game_engines

Sorry for my bad english.