Closed Bug 1643989 Opened 4 years ago Closed 4 years ago

Full screenshot is incomplete with hardware acceleration option enabled

Categories

(Core :: Graphics: Canvas2D, defect)

77 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox83 --- affected
firefox84 --- unaffected
firefox85 --- unaffected

People

(Reporter: haswellready, Unassigned)

Details

(Keywords: regressionwindow-wanted)

Attachments

(1 file)

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

Steps to reproduce:

When I make a full screenshot of a long web page I get an incomplete result image.
I make a screenshot in this way: right click on web page -> Screenshot -> Full screenshot.
When I turn off hardware acceleration there is no issue.
I've updated graphic driver and it didn't help.
Here are results for Wikipedia.

Actual results:

  • screenshot is not full with hardware acceleration turned on

Expected results:

  • screenshot is full with hardware acceleration turned on

Hardware acceleration turned on: see an empty space at the bottom of web page: https://i.imgur.com/visa4kg.jpg
Hardware acceleration turned off: everything is OK: https://i.imgur.com/Fe8t8Tx.jpg

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Screenshots

The severity field is not set for this bug.
:ianbicking, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ianb)
Component: Screenshots → Graphics
Flags: needinfo?(ianb)
Product: Firefox → Core

Thank you for filing the bug!
Do you have WebRender enabled? Please attach the about:support output.
If it's not enabled, please try running with gfx.webrender.all = true setting and see if it makes a difference.
A quick check on Linux/WR shows screenshots to be taken normally for me.

Severity: -- → S3
Flags: needinfo?(haswellready)

This option didn't help: gfx.webrender.all = true
The issue still exists.

Flags: needinfo?(haswellready)
Attached file about_support.txt (deleted) —

Here is my setting you've asked for.

Thank you! I'm not able to see that on NV/Linux. Is this happening everywhere, or just on some specific (e.g. very long) pages?

Blocks: gfx-triage

It happens for long pages only.
On any site.

The screenshot is captured by running drawWindow on a 2d canvas in the content process: https://searchfox.org/mozilla-central/rev/277ab3925eae21b419167a34624ec0ab518d0c94/browser/extensions/screenshots/selector/shooter.js#80 (until bug 1664444 is fixed).
When hardware acceleration is used, we use Direct2D for canvas.

I thought we had code that fell back to software canvas for large canvas sizes. But if we do, it's buried somewhere in PersistentBufferProvider code, I think... Bob, do you know if we apply different DrawTarget size limits for D2D vs Skia somewhere? Should we?

Status: UNCONFIRMED → NEW
Component: Graphics → Canvas: 2D
Ever confirmed: true
Flags: needinfo?(bobowencode)
QA Whiteboard: [qa-regression-triage]

I can reproduce this issue only on Windows 8.1 (x86) (Firefox Release 82.0.3 - new profile, without addons) but the window needs to be maximized before taking the screenshot. Otherwise, this issue is not reproducible. Could not reproduce on Win10 and macOS.

haswellready, can you check if you can use Mozregression to track down what caused this issue? I tried it out as well, but Python is not getting installed on my Win8.1 and the GUI version is not working for some reason.

Flags: needinfo?(haswellready)

Additional testing done revealed this works fine on the following versions:
85.0a1 (2020-11-20) (32-bit) unaffected
84.0b3 (32-bit) unaffected

Issue reproducible on:
83.0 (32-bit) affected

Seems like it got fixed in Beta and Nightly.
haswellready, scratch what I asked you before, can you also confirm this is working for you on latest Beta and Nightly? Here is where you can download it from: https://www.mozilla.org/en-US/firefox/channel/desktop/

I've checked and confirm that it is fixed now on the latest Nightly 85.0a1 (2020-11-17) (64-bit).
So it could be closed.

Flags: needinfo?(haswellready)

After long 6 months, thanks to everybody!

It would still be interesting to use mozregression to find out what fixed it, but it's less of a priority now.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bobowencode)
Resolution: --- → WORKSFORME
No longer blocks: gfx-triage
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: