Closed Bug 1744334 Opened 3 years ago Closed 8 months ago

Glyph corruption issues with Windows 11 (e.g. printer dialog)

Categories

(Core :: Graphics: WebRender, defect, P3)

Firefox 94
defect

Tracking

()

RESOLVED INACTIVE

People

(Reporter: n.rottgardt, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 3 obsolete files)

Attached image firefox_7hpkS39nh9.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Installed Firefox on a fresh Windows 11 installation on a Dell 7706 2in1 with IRIS XE and nvidia MX350. It does not happen on the same setup with Windows 10 Home.

Reproduction:

  1. press CTRL + P
  2. Click on the printer dropdown to open the list of printers

Edition Windows 11 Home
Version 21H2
Installiert am ‎08.‎10.‎2021
Betriebssystembuild 22000.348
Leistung Windows Feature Experience Pack 1000.22000.348.0

Dell 3221 UHD monitor

Actual results:

There are drawing issues in the printer dropdown (CTRL + P dialog) and also the tab titles are not drawn correctly everytime. Also it flickers...

Expected results:

Print dialog should be drawn correctly like also the tab titles

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Setup' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Printing: Setup
Product: Firefox → Core

Hi, what makes you think this is a problem in Firefox code, and not with your graphics driver or Windows libraries providing system print dialogs? Have you brought this up in a support forum?

Flags: needinfo?(n.rottgardt)

(In reply to Andre Klapper from comment #2)

Hi, what makes you think this is a problem in Firefox code, and not with your graphics driver or Windows libraries providing system print dialogs? Have you brought this up in a support forum?

Hi,

it happens with Firefox and Thunderbold only. I also opened a question in Microsoft Support Forum and simply ask to update all drivers and if this is constrained to one product I should open a ticket there. As it happens with Mozilla products only it is perhaps an issue with a shared library or also a windows library. The printer dialog does not look like windows standard...

Attached screenshot from the tabs. Sometimes the grey background is only visible as a triangle (red lines). But I could not reproduce it, it happens from time to time. And also that the text is not written fine. Perhaps it is a problem with true type fonts?

Flags: needinfo?(n.rottgardt)
Attached image firefox_i06vYsTetj2.png

Might be glyph correction.

Summary: Draw issue with Windows 11 (e.g. printer dialog) → Glyph corruption issues with Windows 11 (e.g. printer dialog)

Could you please post the result of about:support?

I guess it's a gfx driver issue, moving to WebRender for now.

Component: Printing: Setup → Graphics: WebRender
Flags: needinfo?(n.rottgardt)

Nical, is this a texture atlasing issue?

Severity: -- → S3
Flags: needinfo?(nical.bugzilla)
Priority: -- → P3

I don't think it's an atlasing issue per se. Probably a shader compilation bug causing it to output garbage or sampling from the wrong place.

The content of the graphics section of about:config would be useful.

Flags: needinfo?(nical.bugzilla)
See Also: → 1701264

My hunch would be that like bug 1701264, this probably reflects a reallocated, corrupted, or failed allocation of a shared texture cache page. The characters only allocated to that page would drop out. Or it could be that binding of that texture is failing sometimes (the flickering maybe?).

Attached file about_support.pdf

As requested the about:support information

Flags: needinfo?(n.rottgardt)

Checked bug 1701264 and it looks more or less similar, but not 100% the same my Webpages are rendered fine everytime.
BTW the system configuration is different:
Mine is Windows 11, Nvidia and Intel, the other bug is Windows 10 and AMD.

This just tries to add in support for drawing certain stroked rects by reusing
existing shaders and geometry. This solves some low-hanging fruit with certain
test-cases while more general stroked geometry can be added at a later time.

Assignee: nobody → lsalzman

Reading back from the WebGL context to the Skia context if we need to fall back
software rasterization can be extremely expensive. In general, it is better to
try to avoid this by rasterizing primitives in software and then uploading them
to a texture.

This generalizes that idea so that when using the default source-over blend
mode, the Skia context can function as a layer that accumulates recently
drawn primitives and blends them via source-over to the WebGL context when
a flush is necessary.

Depends on D135259

This generalizes the CacheEntry infrastructure to implement path caching.
This allows us to cache recently drawn paths to a texture which can be then
drawn without falling back to Skia.

Paths using simple solid color patterns will be drawn as alpha masks that
can then have the color applied in the shader. For now, other pattern types
have the pattern baked into the texture to avoid having to complicate the
shader setup for now. In the future, other pattern types could be supported
with new shaders to allow those to be cached as alpha masks as well.

In the service of this, comparison and cloning operators were added to the
Pattern classes to make remembering and matching against them easier for
cache entries.

Depends on D135260

Comment on attachment 9257905 [details]
Bug 1744334 - Support drawing simple stroked geometry. r?jrmuizel

Revision D135259 was moved to bug 1745556. Setting attachment 9257905 [details] to obsolete.

Attachment #9257905 - Attachment is obsolete: true

Comment on attachment 9257906 [details]
Bug 1744334 - Support layering of Skia and WebGL contexts in accelerated canvas. r?jrmuizel

Revision D135260 was moved to bug 1745556. Setting attachment 9257906 [details] to obsolete.

Attachment #9257906 - Attachment is obsolete: true

Comment on attachment 9257907 [details]
Bug 1744334 - Cache paths to textures to avoid falling back to Skia. r?jrmuizel

Revision D135261 was moved to bug 1745556. Setting attachment 9257907 [details] to obsolete.

Attachment #9257907 - Attachment is obsolete: true
Assignee: lsalzman → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 8 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: