support glyph transforms with alpha and mono font render modes #2095
Conversation
|
Could we add a reftest for transform + alpha (png reference on Linux would be fine), and do a gecko try run? |
lsalzman
force-pushed
the
transformed-alpha
branch
from
0d8b060
to
8625701
Compare
|
Try run in progress, working on adding a reftest now. |
lsalzman
force-pushed
the
transformed-alpha
branch
2 times, most recently
from
9a41a19
to
2988fc0
Compare
|
Reviewed 9 of 9 files at r1. Comments from Reviewable |
|
Looks great! Delegating since this is ready to go but will need rebasing once the other pending font PR merges. @bors-servo delegate+ |
|
✌️ @lsalzman can now approve this pull request |
|
@bors-servo r+ |
|
📌 Commit 2988fc0 has been approved by |
|
🔒 Merge conflict |
|
☔ The latest upstream changes (presumably #2094) made this pull request unmergeable. Please resolve the merge conflicts. |
lsalzman
force-pushed
the
transformed-alpha
branch
from
2988fc0
to
7ed043d
Compare
|
@bors-servo r+ |
|
📌 Commit 45ac4ad has been approved by |
support glyph transforms with alpha and mono font render modes This fixes the downstream Gecko bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1413793 Essentially, the bug on display above is that we have FontRenderMode::Alpha with a scaling content transform. But glyph transforms only work in subpixel, so the alpha glyph gets rendered at pre-transformed scale, and then later transformed, resulting in the blurry mess. After discussion with Glenn, we decided it made sense to extend support for glyph transforms to the other render modes than just subpixel, which is fairly trivial and does the job. The only render mode that does not get glyph transforms is FontRenderMode::Bitmap, since we're assuming we're pulling a pre-rasterized glyph out of the font and pre-transforming it would be a waste. The only little bit of complexity here was that bitmap handling in the Windows backend needed some cleaning. I made FontRenderMode::Bitmap now tie in with requests of FontInstancePlatformOptions::use_embedded_bitmap. Further, I cleaned up handling of the dwrite modes to more closely match Skia, so that essentially we punt to GDI more often and more consistently when we need to. <!-- 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/2095) <!-- Reviewable:end -->
|
☀️ Test successful - status-appveyor, status-travis |
This fixes the downstream Gecko bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1413793
Essentially, the bug on display above is that we have FontRenderMode::Alpha with a scaling content transform. But glyph transforms only work in subpixel, so the alpha glyph gets rendered at pre-transformed scale, and then later transformed, resulting in the blurry mess.
After discussion with Glenn, we decided it made sense to extend support for glyph transforms to the other render modes than just subpixel, which is fairly trivial and does the job. The only render mode that does not get glyph transforms is FontRenderMode::Bitmap, since we're assuming we're pulling a pre-rasterized glyph out of the font and pre-transforming it would be a waste.
The only little bit of complexity here was that bitmap handling in the Windows backend needed some cleaning. I made FontRenderMode::Bitmap now tie in with requests of FontInstancePlatformOptions::use_embedded_bitmap. Further, I cleaned up handling of the dwrite modes to more closely match Skia, so that essentially we punt to GDI more often and more consistently when we need to.
This change is