Gian-Carlo Pascutto [:gcp] Reporter
	Description • 8 years ago

Nightly, Windows 10, AMD Radeon R9 390, Crimson 16.9.2. This is a very recent regression.

See screenshot. The same behavior is visible on irccloud or even Bugzilla.

The first frame doesn't necessarily trigger this behavior, but it generally comes after scrolling a bit.

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 1 • 8 years ago

Even when fonts are not cut off as pictured, I have the impression they're being rendered too thin.

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 2 • 8 years ago

Here's it happening on Bugzilla.

	Jim Mathies [:jimm]
	Comment 3 • 8 years ago

I'm seeing this as well.

	Jim Mathies [:jimm]
	Comment 4 • 8 years ago

[Tracking Requested - why for this release]:
recent regression in nightly

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 5 • 8 years ago

 4:05.74 INFO: Last good revision: 2f21fdc94dcfb4635ed5218ea3d2dd43fb332d07
 4:05.74 INFO: First bad revision: aeb3209d58fee9d5ecce3832986acc81b7d720da
 4:05.74 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2f21fdc94dcfb4635ed5218ea3d2dd43fb332d07&tochange=aeb3209d58fee9d5ecce3832986acc81b7d720da

aeb3209d58fe	Matt Woodrow — Bug 1302918 - Remove old Compositor sharing code. r=nical
2b4457a0428b	Matt Woodrow — Bug 1302918 - Add PVideoBridge to share textures with the compositor. r=dvander,nical
cb3267d9e339	Matt Woodrow — Bug 1303897 - Part 3: Remove unnecessary param to InitIPDLActor. r=nical
0af32711ba65	Matt Woodrow — Bug 1303897 - Part 2: Use TextureForwarder for TextureClientRecycleAllocator. r=nical
11dff62f0ef5	Matt Woodrow — Bug 1303897 - Part 1: Use TextureForwarder for Image::GetTextureClient. r=nical

	Matt Woodrow (:mattwoodrow)
	Comment 6 • 8 years ago

Are you sure about this regression range?

It seems very unlikely that this change affected text rendering. There were some glyph changes that went in at almost the same time, those seem much more likely.

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 7 • 8 years ago

It's always possible that I put a "good" in mozregression whereas it should've been a "bad".

That said, the odds of accidentally landing on a gfx change...

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 8 • 8 years ago

 3:22.38 INFO: Narrowed inbound regression window from [2f21fdc9, d343d428] (3 revisions) to [2f21fdc9, aeb3209d] (2 revisions) (~1 steps left)
 3:22.38 INFO: Oh noes, no (more) inbound revisions :(
 3:22.38 INFO: Last good revision: 2f21fdc94dcfb4635ed5218ea3d2dd43fb332d07
 3:22.38 INFO: First bad revision: aeb3209d58fee9d5ecce3832986acc81b7d720da
 3:22.39 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2f21fdc94dcfb4635ed5218ea3d2dd43fb332d07&tochange=aeb3209d58fee9d5ecce3832986acc81b7d720da

Exact same push on inbound. So yeah, I definitely blame you Matt :-)

	The 8472
	Comment 9 • 8 years ago

I don't know if it's related but i'm seeing wonky pixel placement in general on nightly, not just the top being cut off.

	Matt Woodrow (:mattwoodrow)
	Comment 10 • 8 years ago

Is this still happening?

I can see how it happened, and bug 1281456 should have fixed it.

	Gian-Carlo Pascutto [:gcp] Reporter
	Comment 11 • 8 years ago

This no longer occurs for me.

	Marcia Knous [:marcia]
	Comment 12 • 8 years ago

No need to track based on Comment 11.

	Julien Cristau [:jcristau]
	Comment 13 • 8 years ago

marking fixed in 52 per comment 11