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

Handle text runs that need split batches, and reduce allocations. #1689

Merged
merged 1 commit into from Sep 12, 2017

Conversation

@glennw
Copy link
Member

glennw commented Sep 11, 2017

Previously, both the normal text run and text shadow code assumed
that all the glyphs in a single text run were placed in the same
texture. This is generally true, but not always. In particular,
a text run that contains a glyph that fits in the texture cache, and
one that is too large for the texture cache would trigger this condition.

Now, create a text shadow batch per texture ID. For normal text runs,
flush and create a new batch each time a glyph is encountered that
belongs to a different source texture.

Also, remove an allocation per text run by using a shared buffer
to store glyphs as they are fetched for a text run. This is a bit
untidy - the caller must provide the fetch buffer since the resource
cache is considered immutable at this point (batching may be
spread across threads in the future). However, since this is such
a hot code path on most pages, it's worth it (typically a 10% CPU
time saving on pages I tested).

The reftests just need to not crash - the content is identical.


This change is Reviewable

@glennw
Copy link
Member Author

glennw commented Sep 11, 2017

r? @nical

Previously, both the normal text run and text shadow code assumed
that all the glyphs in a single text run were placed in the same
texture. This is generally true, but not *always*. In particular,
a text run that contains a glyph that fits in the texture cache, and
one that is too large for the texture cache would trigger this condition.

Now, create a text shadow batch per texture ID. For normal text runs,
flush and create a new batch each time a glyph is encountered that
belongs to a different source texture.

Also, remove an allocation per text run by using a shared buffer
to store glyphs as they are fetched for a text run. This is a bit
untidy - the caller must provide the fetch buffer since the resource
cache is considered immutable at this point (batching may be
spread across threads in the future). However, since this is such
a hot code path on most pages, it's worth it (typically a 10% CPU
time saving on pages I tested).

The reftests just need to not crash - the content is identical.
@glennw glennw force-pushed the glennw:text-run-opt-fixes branch from d32879a to 1ce4ac1 Sep 11, 2017
@JerryShih
Copy link
Contributor

JerryShih commented Sep 11, 2017

With this, do we still need the #1597?

@nical
Copy link
Collaborator

nical commented Sep 11, 2017

@bors-servo
Copy link
Contributor

bors-servo commented Sep 11, 2017

📌 Commit 1ce4ac1 has been approved by nical

@bors-servo
Copy link
Contributor

bors-servo commented Sep 11, 2017

Testing commit 1ce4ac1 with merge 30c35e4...

bors-servo added a commit that referenced this pull request Sep 11, 2017
Handle text runs that need split batches, and reduce allocations.

Previously, both the normal text run and text shadow code assumed
that all the glyphs in a single text run were placed in the same
texture. This is generally true, but not *always*. In particular,
a text run that contains a glyph that fits in the texture cache, and
one that is too large for the texture cache would trigger this condition.

Now, create a text shadow batch per texture ID. For normal text runs,
flush and create a new batch each time a glyph is encountered that
belongs to a different source texture.

Also, remove an allocation per text run by using a shared buffer
to store glyphs as they are fetched for a text run. This is a bit
untidy - the caller must provide the fetch buffer since the resource
cache is considered immutable at this point (batching may be
spread across threads in the future). However, since this is such
a hot code path on most pages, it's worth it (typically a 10% CPU
time saving on pages I tested).

The reftests just need to not crash - the content is identical.

<!-- 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/1689)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Sep 11, 2017

💔 Test failed - status-travis

@glennw
Copy link
Member Author

glennw commented Sep 11, 2017

Yup, we still need #1597 - that solves a different issue.

@bors-servo retry

@bors-servo
Copy link
Contributor

bors-servo commented Sep 11, 2017

Testing commit 1ce4ac1 with merge 4afda07...

bors-servo added a commit that referenced this pull request Sep 11, 2017
Handle text runs that need split batches, and reduce allocations.

Previously, both the normal text run and text shadow code assumed
that all the glyphs in a single text run were placed in the same
texture. This is generally true, but not *always*. In particular,
a text run that contains a glyph that fits in the texture cache, and
one that is too large for the texture cache would trigger this condition.

Now, create a text shadow batch per texture ID. For normal text runs,
flush and create a new batch each time a glyph is encountered that
belongs to a different source texture.

Also, remove an allocation per text run by using a shared buffer
to store glyphs as they are fetched for a text run. This is a bit
untidy - the caller must provide the fetch buffer since the resource
cache is considered immutable at this point (batching may be
spread across threads in the future). However, since this is such
a hot code path on most pages, it's worth it (typically a 10% CPU
time saving on pages I tested).

The reftests just need to not crash - the content is identical.

<!-- 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/1689)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Sep 11, 2017

💔 Test failed - status-travis

@glennw
Copy link
Member Author

glennw commented Sep 11, 2017

@bors-servo retry

  • more ssl builder issues
@bors-servo
Copy link
Contributor

bors-servo commented Sep 12, 2017

Testing commit 1ce4ac1 with merge cd18555...

bors-servo added a commit that referenced this pull request Sep 12, 2017
Handle text runs that need split batches, and reduce allocations.

Previously, both the normal text run and text shadow code assumed
that all the glyphs in a single text run were placed in the same
texture. This is generally true, but not *always*. In particular,
a text run that contains a glyph that fits in the texture cache, and
one that is too large for the texture cache would trigger this condition.

Now, create a text shadow batch per texture ID. For normal text runs,
flush and create a new batch each time a glyph is encountered that
belongs to a different source texture.

Also, remove an allocation per text run by using a shared buffer
to store glyphs as they are fetched for a text run. This is a bit
untidy - the caller must provide the fetch buffer since the resource
cache is considered immutable at this point (batching may be
spread across threads in the future). However, since this is such
a hot code path on most pages, it's worth it (typically a 10% CPU
time saving on pages I tested).

The reftests just need to not crash - the content is identical.

<!-- 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/1689)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Sep 12, 2017

☀️ Test successful - status-travis
Approved by: nical
Pushing cd18555 to master...

@bors-servo bors-servo merged commit 1ce4ac1 into servo:master Sep 12, 2017
2 of 3 checks passed
2 of 3 checks passed
continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
This was referenced Sep 12, 2017
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

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