Skip to content

Conversation

@changm
Copy link
Contributor

@changm changm commented Jan 23, 2017

Essentially replicating this from gecko - http://searchfox.org/mozilla-central/source/gfx/2d/DrawTargetSkia.cpp#1390

I contemplated various ways to pass glyph rendering options to rasterize_glyphs either through traits or some struct, but we don't do anything special for linux or mac, so using a option seemed like the best thing, even though it exposes "dwrite" and forces the other platforms to use it. Nor could I find a clean way to pass derived types with data only as traits seemed to only pass down method interfaces.


This change is Reviewable

@kvark kvark self-requested a review January 24, 2017 01:18
@bors-servo
Copy link
Contributor

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

@glennw
Copy link
Member

glennw commented Jan 24, 2017

Do these options need to be stored per text run dynamically? For instance, can they be set once per frame / font or at init time perhaps? How often do they change?

@changm
Copy link
Contributor Author

changm commented Jan 24, 2017

They can't be stored once per frame, it depends on the text run :(. Layout determines whether or not to enable these options for each text run. Even for the same font, depending on the font size, the options can change.

@glennw
Copy link
Member

glennw commented Jan 24, 2017

OK, in that case, how about we rename the struct to just be GlyphOptions, and then we can specify which platforms each field applies to. This will allow us to use the same struct for other platform-specific options in the future if we need to.

@changm
Copy link
Contributor Author

changm commented Jan 24, 2017

How do you specify how each field applies to which platform? I couldn't find something like that. I thought about going the GlyphOptions route but we don't use that for CG/Unix and I'd rather keep it very explicit what it's for. That's also why I passed it in as an Option rather than the full struct.

@glennw
Copy link
Member

glennw commented Jan 24, 2017

You can use cfg() on each field to make it only available on that platform - but I was actually just suggesting a comment above each field specifying that this applies to Windows only. So I think if we just rename DWriteGlyphOptions -> GlyphOptions and add a comment for each of the two fields saying they only apply to Windows, that would be fine for now.

Copy link
Member

@kvark kvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that DWriteGlyphOptions needs to be renamed, otherwise looks good.

@changm
Copy link
Contributor Author

changm commented Jan 24, 2017

Thanks for the review! Renamed and a comment added saying that GlyphOptions are only used on windows for now.

@glennw
Copy link
Member

glennw commented Jan 25, 2017

@bors-servo r+

@bors-servo
Copy link
Contributor

📌 Commit c5d6838 has been approved by glennw

@bors-servo
Copy link
Contributor

⌛ Testing commit c5d6838 with merge 38e57d8...

bors-servo pushed a commit that referenced this pull request Jan 25, 2017
Pipe dwrite rendering options to rasterize_glyphs

Essentially replicating this from gecko - http://searchfox.org/mozilla-central/source/gfx/2d/DrawTargetSkia.cpp#1390

I contemplated various ways to pass glyph rendering options to rasterize_glyphs either through traits or some struct, but we don't do anything special for linux or mac, so using a option seemed like the best thing, even though it exposes "dwrite" and forces the other platforms to use it. Nor could I find a clean way to pass derived types with data only as traits seemed to only pass down method interfaces.

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

☀️ Test successful - status-travis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants