mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-21 01:05:45 +00:00
5455bb5b62
The format for stacking contexts in the built display list goes from PushStackingContext item push_iter of Vec<FilterOp> to SetFilterOps item push_iter of Vec<FilterOp> 1st SetFilterData item push_iter of array of func types push_iter funcR values push_iter funcG values push_iter funcB values push_iter funcA values . . . nth SetFilterData item push_iter of array of func types push_iter funcR values push_iter funcG values push_iter funcB values push_iter funcA values PushStackingContext item We need separate a SetFilterData item for each filter because we can't push_iter a variable sized thing. When we iterate over the built display list to flatten it we work similarly to how gradients work with a SetGradientStops item before the actual gradient item. So when we see SetFilterOps or SetFilterData we use them to fill out values on the built display list iterator but don't those items return them to the iterator user and instead continue iterating until we hit the PushStackingContext item, at which point to the iterator consumer it appears as those the FilterOps and FilterDatas were on the PushStackingContext item. (This part is trickier too since we need a TempFilterData type that just holds ItemRange's until we get the actual bytes later.) Do we need to clear cur_filters and cur_filter_data at some point to prevent them from getting ready by items for which they do not apply? |
||
|---|---|---|
| .. | ||
| common | ||
| alpha_perf.rs | ||
| animation.rs | ||
| basic.rs | ||
| blob.rs | ||
| Cargo.toml | ||
| document.rs | ||
| frame_output.rs | ||
| iframe.rs | ||
| image_resize.rs | ||
| multiwindow.rs | ||
| README.md | ||
| scrolling.rs | ||
| texture_cache_stress.rs | ||
| yuv.rs | ||
Examples
This directory contains a collection of examples which uses the WebRender API.
To run an example e.g. basic, try:
cargo run --bin basic