Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port normal (css) style borders to be interned primitives. #3342

Merged
merged 1 commit into from Nov 24, 2018

Conversation

@gw3583
Copy link
Collaborator

gw3583 commented Nov 23, 2018

This is mostly a straightforward conversion of normal borders
to make use of primitive interning.

It also adds support during batching and clip task creation for
interned primitives that make use of segments. This is needed
for porting the rest of the primitives, and should make the
conversion of the other primitive types simple.


This change is Reviewable

@gw3583
Copy link
Collaborator Author

gw3583 commented Nov 23, 2018

r? anyone

Try run looks good (sans seemingly unrelated intermittents):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=858b26bf8844094a5870f8c172d88249273ff90f

@gw3583 gw3583 force-pushed the gw3583:intern-normal-borders branch from d05c356 to 0c71b1b Nov 23, 2018
@gw3583
Copy link
Collaborator Author

gw3583 commented Nov 23, 2018

Added a follow up commit that also ports image borders to be interned.

New pending try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=02be9f170cef1af94e62ffdb8fce438d354836fa

@gw3583
Copy link
Collaborator Author

gw3583 commented Nov 23, 2018

Some of these changes are quite messy, with duplicated code in places. This could definitely do with a tidy / clean up pass once all the primitive types are ported and we remove the BrushPrimitive type.

@bors-servo
Copy link
Contributor

bors-servo commented Nov 23, 2018

The latest upstream changes (presumably #3332) made this pull request unmergeable. Please resolve the merge conflicts.

@gw3583 gw3583 force-pushed the gw3583:intern-normal-borders branch from 0c71b1b to 7b5ec62 Nov 23, 2018
@gw3583
Copy link
Collaborator Author

gw3583 commented Nov 23, 2018

Squashed and rebased on the picture caching commit.

Try run looks good, I think. There are a couple of crash test failures (with known intermittents), and a border failure in R1 on OSX. The border failure seems to be text related, I think it's probably due to one of the other recent commits in master?

@kvark
kvark approved these changes Nov 24, 2018
Copy link
Member

kvark left a comment

:lgtm: I don't think there are any blockers

Reviewed 14 of 14 files at r1.
Reviewable status: all files reviewed, 13 unresolved discussions (waiting on @gw3583)


webrender/src/border.rs, line 107 at r1 (raw file):

#[cfg_attr(feature = "replay", derive(Deserialize))]
#[derive(Debug, Clone, Hash, Eq, PartialEq)]
pub struct NormalBorderAu {

if it matches NormalBorder outside of Au vs f32, can we just have NormalBoder<Au> and NormalBorder<f32>?


webrender/src/display_list_flattener.rs, line 1792 at r1 (raw file):

                                let descriptor = BrushSegmentDescriptor {
                                    segments: SmallVec::from_vec(segments),

we might as well just keep a Vec here - I'll fix up some allocations in follow-ups (if we proceed like this)


webrender/src/prim_store.rs, line 351 at r1 (raw file):

        font: FontInstance,
        offset: LayoutVector2DAu,
        glyphs: Vec<GlyphInstance>,

Now that I'm looking at it, why does primitive key kind have a list of glyph instances? Esp since PrimitiveContainer has that list as well


webrender/src/prim_store.rs, line 372 at r1 (raw file):

        request: ImageRequest,
        widths: LayoutSideOffsetsAu,
        width: i32,

any reason this isn't some TypedSize2D<i32, ..>?


webrender/src/prim_store.rs, line 475 at r1 (raw file):

    },
    NormalBorder {
        template: Box<NormalBorderTemplate>,

does this need to be a box?


webrender/src/prim_store.rs, line 850 at r1 (raw file):

/// Information about how to cache a border segment,
/// along with the current render task cache entry.
#[cfg_attr(feature = "capture", derive(Serialize))]

I don't know if this is required here, but I'm happy to see more stuff being serialized. Just gives us a better chance of looking at the captures later down the road ;)


webrender/src/prim_store.rs, line 1718 at r1 (raw file):

    },
    ImageBorder {
        request: ImageRequest,

if we put those fields into a (generic) structure, we can re-use it in PrimitiveKeyKind


webrender/src/prim_store.rs, line 2114 at r1 (raw file):

    pub glyph_keys: GlyphKeyStorage,

    pub border_cache_handles: BorderHandleStorage,

let's keep a good tradition of documenting things :)


webrender/src/prim_store.rs, line 2945 at r1 (raw file):

                    handles.push(frame_state.resource_cache.request_render_task(
                        cache_key.clone(),

redundant clone() ?


webrender/src/prim_store.rs, line 2973 at r1 (raw file):

                    .scratch
                    .border_cache_handles
                    .extend(handles);

looks like we could have a similar scheme here as we do for GPU cache - some sort of accessor temporary that allows writing directly to the storage, instead of collecting into a SmallVec first like we do here


webrender/src/prim_store.rs, line 2978 at r1 (raw file):

                PrimitiveInstanceKind::ImageBorder { .. },
                PrimitiveTemplateKind::ImageBorder { .. }
            ) => {

nothing to do here?


webrender/src/storage.rs, line 81 at r1 (raw file):

    }

    pub fn clear(&mut self) {

we need to add an Epoch to the Index<T> under cfg(debug_assertions), bumping it when the storage gets cleared/recycled
this is fine to do later, I'll make a note for myself ;)


webrender_api/src/units.rs, line 227 at r1 (raw file):

}

impl AuHelpers<LayoutSideOffsetsAu> for LayoutSideOffsets {

I noticed that there is a few places where we are manually converting some XxxSideoffsets between Au and what not.
Can we make this implementation generic over U (being the pixel type), so that the other places can avoid re-implementing it (should be easy to find by "from_32_px")?

This is mostly a straightforward conversion of borders
to make use of primitive interning.

It also adds support during batching and clip task creation for
interned primitives that make use of segments. This is needed
for porting the rest of the primitives, and should make the
conversion of the other primitive types simple.
@gw3583 gw3583 force-pushed the gw3583:intern-normal-borders branch from 7b5ec62 to 9b18fe3 Nov 24, 2018
Copy link
Collaborator Author

gw3583 left a comment

Reviewable status: all files reviewed, 13 unresolved discussions (waiting on @kvark)


webrender/src/border.rs, line 107 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

if it matches NormalBorder outside of Au vs f32, can we just have NormalBoder<Au> and NormalBorder<f32>?

After some discussions with Matt and Dan regarding the cost we're seeing in profiles of the Au <-> f32 rounding conversions, we're planning to switch to hashing floats. This should be fine since Gecko already quantizes the native data in Au first anyway. Once we do that, this struct distinction will disappear.


webrender/src/display_list_flattener.rs, line 1792 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we might as well just keep a Vec here - I'll fix up some allocations in follow-ups (if we proceed like this)

I figured I'd leave the existing brush code as similar as possible - the segmenting on those remaining primitives is minimal. Later this week, all of those primitives will be switched to using the prim storage.


webrender/src/prim_store.rs, line 351 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

Now that I'm looking at it, why does primitive key kind have a list of glyph instances? Esp since PrimitiveContainer has that list as well

Because we want to uniquely identify a text run so we need to has the contents. This is also what the glyph instances in the primitive template are derived from.


webrender/src/prim_store.rs, line 372 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

any reason this isn't some TypedSize2D<i32, ..>?

Only because it's a direct port from the existing primitive code :)


webrender/src/prim_store.rs, line 475 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

does this need to be a box?

Yep - the size of this structure is very sensitive on some of the talos tests. We're investigating some other options, such as keeping these in separate interners per-prim-type, so I consider Box<> here a temporary solution.


webrender/src/prim_store.rs, line 850 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I don't know if this is required here, but I'm happy to see more stuff being serialized. Just gives us a better chance of looking at the captures later down the road ;)

Yup, it's required - border segments are now calculated only once when a new border is interned during scene building, rather than once each new scene in the frame builder.


webrender/src/prim_store.rs, line 1718 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

if we put those fields into a (generic) structure, we can re-use it in PrimitiveKeyKind

Yep, that makes sense - I'll add it to my notes for cleaning this stuff up.


webrender/src/prim_store.rs, line 2114 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

let's keep a good tradition of documenting things :)

Done


webrender/src/prim_store.rs, line 2945 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

redundant clone() ?

Indeed, fixed!


webrender/src/prim_store.rs, line 2973 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

looks like we could have a similar scheme here as we do for GPU cache - some sort of accessor temporary that allows writing directly to the storage, instead of collecting into a SmallVec first like we do here

That's a good idea, seems like it'd be useful in multiple places.


webrender/src/prim_store.rs, line 2978 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

nothing to do here?

No, these primitives only update in their template, the instances don't need to do anything.


webrender/src/storage.rs, line 81 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we need to add an Epoch to the Index<T> under cfg(debug_assertions), bumping it when the storage gets cleared/recycled
this is fine to do later, I'll make a note for myself ;)

I agree, this sounds good.


webrender_api/src/units.rs, line 227 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I noticed that there is a few places where we are manually converting some XxxSideoffsets between Au and what not.
Can we make this implementation generic over U (being the pixel type), so that the other places can avoid re-implementing it (should be easy to find by "from_32_px")?

Yep, although probably not necessary if we go with the float hashing mentioned above.

@gw3583
Copy link
Collaborator Author

gw3583 commented Nov 24, 2018

@kvark Thanks for the review! I think I answered / addressed all the comments.

Going to merge now as you mentioned there's no blockers, and I want to avoid rebasing it too often. Please just comment here if there's further follow ups based on those review comments.

@bors-servo r=kvark

@bors-servo
Copy link
Contributor

bors-servo commented Nov 24, 2018

📌 Commit 9b18fe3 has been approved by kvark

@bors-servo
Copy link
Contributor

bors-servo commented Nov 24, 2018

Testing commit 9b18fe3 with merge 90fa51c...

bors-servo added a commit that referenced this pull request Nov 24, 2018
Port normal (css) style borders to be interned primitives.

This is mostly a straightforward conversion of normal borders
to make use of primitive interning.

It also adds support during batching and clip task creation for
interned primitives that make use of segments. This is needed
for porting the rest of the primitives, and should make the
conversion of the other primitive types simple.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3342)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 24, 2018

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: kvark
Pushing 90fa51c to master...

@bors-servo bors-servo merged commit 9b18fe3 into servo:master Nov 24, 2018
3 of 4 checks passed
3 of 4 checks passed
code-review/reviewable 1 file, 13 discussions left (kvark)
Details
Taskcluster (pull_request) TaskGroup: success
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Nov 27, 2018
…a9bd159ab398 (WR PR #3342). r=kats

servo/webrender#3342

Differential Revision: https://phabricator.services.mozilla.com/D13023

--HG--
extra : moz-landing-system : lando
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 3, 2019
…a9bd159ab398 (WR PR #3342). r=kats

servo/webrender#3342

Differential Revision: https://phabricator.services.mozilla.com/D13023

UltraBlame original commit: be07c850ed1562add8526b5c1e06463cbd758b68
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 3, 2019
…a9bd159ab398 (WR PR #3342). r=kats

servo/webrender#3342

Differential Revision: https://phabricator.services.mozilla.com/D13023

UltraBlame original commit: be07c850ed1562add8526b5c1e06463cbd758b68
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 3, 2019
…a9bd159ab398 (WR PR #3342). r=kats

servo/webrender#3342

Differential Revision: https://phabricator.services.mozilla.com/D13023

UltraBlame original commit: be07c850ed1562add8526b5c1e06463cbd758b68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.