1305381 - Font glyphs cut off at the top

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Attachment: fontcut.png

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.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

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

Comment 2

[Gian-Carlo Pascutto [:gcp]]

Attachment: bugzilla.png

Here's it happening on Bugzilla.

Comment 3

[Jim Mathies [:jimm]]

I'm seeing this as well.

Comment 4

[Jim Mathies [:jimm]]

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

Comment 5

[Gian-Carlo Pascutto [:gcp]]

 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

Comment 6

[Matt Woodrow (:mattwoodrow)]

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.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

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...

Comment 8

[Gian-Carlo Pascutto [:gcp]]

 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 :-)

Comment 9

[The 8472]

Attachment: font.png

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.

Comment 10

[Matt Woodrow (:mattwoodrow)]

Is this still happening?

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

Comment 11

[Gian-Carlo Pascutto [:gcp]]

This no longer occurs for me.

Comment 12

[Marcia Knous [:marcia]]

No need to track based on Comment 11.

Comment 13

[Julien Cristau [:jcristau]]

marking fixed in 52 per comment 11