Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign updetermine whether a font has bitmaps only when fetching glyphs #2198
Conversation
lsalzman
force-pushed the
lsalzman:delayed-bitmaps
branch
4 times, most recently
from
cc3903d
to
c3f68d1
|
|
|
Reviewed 13 of 13 files at r1. Comments from Reviewable |
|
@bors-servo r+ |
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 8, 2017
determine whether a font has bitmaps only when fetching glyphs This fixes downstream Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1422408 Some TTFs can contain both fixed size bitmap strikes and scalable outlines. The proper selection procedure is to check if there are strikes *exactly* matching the desired size, otherwise use the scalable outlines. But we violate this currently by always trying to use the bitmap strikes if they are available even when scalable outlines are present. The problem is that we don't know the actual resolved size at the time we decide to mark a FontInstance with FontRenderMode::Bitmap when a FontInstance is newly created, so we never used that to make the decision. To fix this, we need to delay deciding whether something is a bitmap until we actually go to fetch the glyph from the cache and essentially when we go to rasterize it. We let the font backend communicate that it is actually a bitmap via the new GlyphFormat::Bitmap (and the existing GlyphFormat::ColorBitmap for emoji). We then need to make sure this gets down to the ps_text_run shader via TextShaderMode, so we can selectively disable subpixel offsets based on whether something is a bitmap. We can't disable subpixel offsetting earlier since we don't know if the font is a bitmap yet when gpu data is written out, and even then, this will depend on size, so a global decision can't be made for all sizes instances of a given TextRunPrimitiveCpu. <!-- 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/2198) <!-- Reviewable:end -->
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 9, 2017
pass subpixel dir to shader via glyph instances instead of text run This is a follow-up to #2198. I overlooked cs_text_run, which will also need to know about subpx_dir. Since we don't break up batches for these text shadow glyphs, and since subpixel direction now depends on the glyph format which is size/transform dependent, it just made a lot more sense to pass it in via the (now) unused user_data2 in the glyph instance. This also moves some decision logic out of the shader. Since all these parameters get routed out of prim.user_dataN almost straight to fetch_glyph, it makes some sense to put subpx_dir there anyway. <!-- 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/2207) <!-- Reviewable:end -->
bors-servo
added a commit
that referenced
this pull request
Dec 9, 2017
pass subpixel dir to shader via glyph instances instead of text run This is a follow-up to #2198. I overlooked cs_text_run, which will also need to know about subpx_dir. Since we don't break up batches for these text shadow glyphs, and since subpixel direction now depends on the glyph format which is size/transform dependent, it just made a lot more sense to pass it in via the (now) unused user_data2 in the glyph instance. This also moves some decision logic out of the shader. Since all these parameters get routed out of prim.user_dataN almost straight to fetch_glyph, it makes some sense to put subpx_dir there anyway. <!-- 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/2207) <!-- Reviewable:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
lsalzman commentedDec 8, 2017
•
edited by larsbergstrom
This fixes downstream Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1422408
Some TTFs can contain both fixed size bitmap strikes and scalable outlines. The proper selection procedure is to check if there are strikes exactly matching the desired size, otherwise use the scalable outlines.
But we violate this currently by always trying to use the bitmap strikes if they are available even when scalable outlines are present. The problem is that we don't know the actual resolved size at the time we decide to mark a FontInstance with FontRenderMode::Bitmap when a FontInstance is newly created, so we never used that to make the decision.
To fix this, we need to delay deciding whether something is a bitmap until we actually go to fetch the glyph from the cache and essentially when we go to rasterize it. We let the font backend communicate that it is actually a bitmap via the new GlyphFormat::Bitmap (and the existing GlyphFormat::ColorBitmap for emoji).
We then need to make sure this gets down to the ps_text_run shader via TextShaderMode, so we can selectively disable subpixel offsets based on whether something is a bitmap. We can't disable subpixel offsetting earlier since we don't know if the font is a bitmap yet when gpu data is written out, and even then, this will depend on size, so a global decision can't be made for all sizes instances of a given TextRunPrimitiveCpu.
This change is