Take screenshot produces artifacts when used on webgl
Categories
(Core :: Graphics, defect, P1)
Tracking
()
People
(Reporter: turkeevm, Assigned: jgilbert)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Steps to reproduce:
- go to cineshader.com
- use "Take screenshot" from right click menu
Also these details may be important.
- Firefox was running on windows 10, gpu is nvidia gtx1070Ti, nvidia driver is version 432.00
- The bug disappears if I disable hardware acceleration
Actual results:
screenshot vaguely remids actual image, but with lot's of random noise
Expected results:
screenshot as if it was taken with disabled hardware acceleration
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
:turkeevm, thanks for reporting! There is a separate bug filed about screenshots with hardware acceleration enabled (Bug 1643989), but I'm not sure if one fix will address both issues. I'm going to redirect this to the graphics team
Comment 4•4 years ago
|
||
Could you attach about:support, please?
Adding to gfx-triage, given that we have multiple reports for this, need to figure out how to schedule a fix.
Umm. I am not sure how do I "attach" it. there is a "Copy text to clipboard"
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Hello! Unfortunately I can't spot the difference between a screen shot taken with hardware acceleration and the one without.
If you could please point me on what to look for so I can look for a regression for this issue afterwards.
Comment 7•4 years ago
|
||
Negritas, the difference should be quite stark. See the two attached screenshots. Maybe try on different hardware?
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Regression back on 7-9 -
Bug 1642994 - Fix SurfaceTexture assertion failure in WebGLContext::GetFrontBuffer r=jgilbert
- WaitForBufferOwnership() must be called before locking the front buffer
- Use mDefaultFB->mFB instead of 0 to fix a freeze in the readPixels call
- SurfaceTexture.releaseTexImage must be called after each use
Differential Revision: https://phabricator.services.mozilla.com/D82944
Comment 9•4 years ago
|
||
I think you meant the other Jeff
Comment 10•4 years ago
|
||
Thank you Jeff Muizelaar for the info!
I have tried using a different nvidia driver (431.60) on a laptop dell g3 with nvidia gtx 1050, I couldn't reproduce the issue even after changing the driver. I think it might be a hardware related issue and unfortunately I don't have such hardware to test.
Reporter | ||
Comment 11•4 years ago
|
||
these guys were able to reproduce the issue. I don't know which hardware did they used though. https://github.com/DevExpress/testcafe/issues/5533
Reporter | ||
Comment 12•4 years ago
|
||
Now I know
NVIDIA GeForce GTX 1660 SUPER
Driver version: 26.21.14.4108
Driver date: 22.10.2019
DirectX version: 12 (FL 12.1)
Assignee | ||
Comment 13•4 years ago
|
||
I can't seem to repro on my AMD GPU machine (82.0.3 or 84nightly). I'll take a look on my NV machines tomorrow, as well as try forcing NV on my hybrid machines with NV dGPUs.
Comment 14•4 years ago
|
||
Interestingly, bug 1643989 appears to report a similar issue, but with WebRender without WebGL, on Windows/Intel GPU
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Still reproducible for me on Win10 Nightly w/ nVidia Quadro P2000 and latest drivers.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 17•3 years ago
|
||
Not reproducible for me on GTX 1070, NVIDIA 471.96 drivers and latest Windows 10.
Comment 19•3 years ago
|
||
Works for me too. Probably fixed by bug 1661869.
Description
•