Use byte indices instead of char indices for text runs
Replace character indices with UTF-8 byte offsets throughout all code dealing with text runs. This eliminates a lot of complexity when converting from one to the other, and interoperates better with the rest of the Rust ecosystem.
For most code this is just a simple replacement of char indices with byte indices. In a few places like glyph storage and text fragment scanning, it also lets us get rid of code that existed only to map between bytes and chars.
Also includes some related fixes to text shaping, discovered while working on this conversion. See the commit messages for details.
r? @pcwalton
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10895)
<!-- Reviewable:end -->
Replace character indices with UTF-8 byte offsets throughout the code dealing
with text shaping and breaking. This eliminates a lot of complexity when
converting from one to the other, and interoperates better with the rest of
the Rust ecosystem.
* Sections like `[dependencies.foo]` can be entries in a `[dependencies]`
section with the `{key = value}` syntax.
* Per-target dependencies can be expressed with more general `cfg(…)`
conditions instead of exact target triples:
https://github.com/rust-lang/cargo/pull/2328
Merge DisplayListEntry into DisplayItem
We don't really need two levels of abstraction for every element in the
DisplayList. This simplifies the complexity of the data structure in
preparation for providing documentation and properly handling scrolling
roots.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10810)
<!-- Reviewable:end -->
Added #[allow(unused_extern_crates)] to silence false positives
* bitflags, lazy_static and matches because macro_use
* alloc_jemalloc because builtin crate
See https://github.com/rust-lang/rust/issues/30849
We don't really need two levels of abstraction for every element in the
DisplayList. This simplifies the complexity of the data structure in
preparation for providing documentation and properly handling scrolling
roots.
Implement scroll, scrollLeft, scrollTop and friends, addressing issue #9650
This is a work in progress to solve https://github.com/servo/servo/issues/9650. Thanks a lot for helping the review.
- [x] scroll
- [x] scrollTo
- [x] scrollBy
- [x] scrollTop (setter and getter)
- [x] scrollLeft (setter and getter)
The setters will be implemented in another PR after this is merged.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9968)
<!-- Reviewable:end -->
Add new compositor message to get scroll_offset;
Add new layout query for computed value of overflow-x/y;
Implement layer_id method for ThreadSafeLayoutNode;
Add new layout query for layer_id;
Implement script interface for getting scrollTop and scrollLeft, as well as relavant helper functions.
Since the display list is already sorted before it is passed to
WebRender, we don't need to pass the stacking level information any
longer. Update webrender, webrender_traits, and gleam.
Empty fragments may need to be layed out to draw borders, padding/background,
and insertion points. (Fragments that consist of discardable whitespace and
control characters, on the other hand, can still be discarded.)
This ends up preserving some useless empty fragments. It's possible we could
avoid this by storing some sort of flag on "important" empty fragments, so we
can discard the rest.
This fixes two problems that could cause scanned text fragments to end up with
incorrect LAST_FRAGMENT_OF_ELEMENT or FIRST_FRAGMENT_OF_ELEMENT flags:
1. If a single unscanned fragment was split into multiple scanned fragments,
then all of them would inherit its flags. We need to clear these flags,
except for the first and last scanned fragment.
2. When an unscanned fragment generated zero scanned fragments, we correctly
called `meld_with_next_inline_fragment` to transfer LAST_FRAGMENT flags to
the preceding fragment, but we didn't do anything to transfer
FIRST_FRAGMENT flags to the following fragment. We can fix this by calling
`meld_with_prev_inline_fragment` on the following fragment.
Factor out a new `meld_with_prev_inline_fragment` method that mirrors the
existing `meld_with_next_inline_fragment`.
This also fixes a bug in `meld_with_next` that was already fixed in the
`meld_with_prev` by @notriddle in #10419. The bug is that it was traversing
the inline context nodes in the wrong order. It should start at the outermost
enclosing node, since the fragments might be at different nesting levels under
some common ancestor.
