I think the best fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1618370 (for now, at least) is to disable DirectComposition mode in WebRender when the system is running at a non-native resolution.

I'm not quite sure how to accurately detect this. Some relevant links that might have useful information:

https://docs.microsoft.com/en-us/windows/win32/api/dxgi1_2/nf-dxgi1_2-idxgioutput1-findclosestmatchingmode1

https://stackoverflow.com/questions/54581535/how-to-detect-native-screen-resolution-or-scaling-factor-of-the-secondary-monito

https://docs.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgiadapter-enumoutputs

https://docs.microsoft.com/en-us/windows/win32/api/dxgi/ns-dxgi-dxgi_output_desc

I take the bug. I confirmed that the problem could be reproduced on my one PC.

Add logs around screen size related infos.

Added log around IDXGIOutput and ScreenHelperWin::RefreshScreens().

These APIs did not provide Active signal resolution:(

But PCs that caused the problem always return 0 at IDXGIOutput6::CheckHardwareCompositionSupport(). When the flags were not 0, I did not see the problem.

The following command was used for testing.

./firefox.exe --wait-for-browser > log.txt 2>&1

:bas, :jrmuizel, :gw, do you have an idea about how to get "Active signal resolution"?

It sounds believable that CheckHardwareCompositionSupport will let us know when the hardware is capable of doing the scaling instead of the DWM but we'd need something else to actually let us know when some kind of scaling is happening.

I don't know if this helps or is relevant? For some odd reason the zoom level is off by 10%, except at 100%. Uhm..

Adding some information about my current understanding / best guess of how this fits together. Please correct if it doesn't seem right to you.

From the Windows GUI, there's three values you can see related to resolution. For the purposes here, ignore Scale setting (I believe it's orthogonal to this issue):

1. Display Resolution - listed in the main "Display Settings" (accessible via right click from desktop)
2. Desktop Resolution - in "Advanced Display Settings" (accessible from the Display Settings)
3. Active Signal Resolution - same location, listed below the Desktop Resolution

Bert tested on a machine with an HD630 (which does have a hardware scaler), and sees:
(1) 2048 x 1152
(2) 2048 x 1152
(3) 3840 x 2160

I tested on a machine with an HD4600 (which doesn't have a hardware scaler), and see:
(1) 2048 x 1152
(2) 3840 x 2160
(3) 3840 x 2160

My best guess as to what this means is:

• Firefox will get a 2048 x 1152 framebuffer to draw into in both cases (== Display Resolution)
• DWM composites into the "Desktop Resolution", i.e. on machine with hardware scaler, it would be 2048 x 1152 output to the GPU to scale up in hardware for the monitor, but on machine without hardware scaler, DWM composites to the 3840 x 2160 framebuffer in software, and sends that to the GPU.

If that seems correct, then I think that we want to disable DC mode for now, when:
(a) Display Resolution != Desktop Resolution AND
(b) CheckHardwareCompositionSupport() returns false

I'm still not sure how to retrieve the Display and Desktop resolutions, and I'm not sure whether CheckHardwareCompositionSupport is related to the hardware scaler specifically, or something else.

Does that make sense to anyone else?

(Just adding that unfortunately FindClosestMatch1 just seems to return the desktop/display resolution, not the upscaling, at least not when used like this:)

DXGI_MODE_DESC1 wanted = { 0 };
wanted.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
DXGI_MODE_DESC1 match  = { 0 };
CHECK_HR( output1->FindClosestMatchingMode1(&wanted, &match, NULL) );

Adapter 0 - Intel(R) UHD Graphics 630
        Output 0 - \\.\DISPLAY1 scale factor monitor 100%
        DesktopCoordinates 0, 0 to 1638, 922
        Display 'CDD'   position 0, 0   Pixels 2048 x 1152      60Hz
FindClosest: 2048 x 1152

If comment 8 is correct, then (b) is unnecessary, I think. It would mean that if Display Resolution != Desktop Resolution that would imply both (1) no hardware scaler is active and (2) a non-native resolution is being used?

I still haven't found a reliable way to determine the values above, although I am still looking.

I think we should go for the backup plan for now - disable DC if CheckHardwareCompositionSupport fails, since we want to get this into the current beta.

Although that will disable DC for more users than required, it's also probably a good thing to de-risk the first rollout of DC, since you could speculate that hardware which does support hardware composition is probably more likely to be newer hardware with more stable drivers.

Does that sound like a reasonable plan Jeff? Sotaro, would you be able to create a patch to check that for Gecko (and then we can get it uplifted to beta too)?

Yep. I think this is a good plan. I think disabling DC if CheckHardwareCompositionSupport is probably a good thing to do even if we didn't have the gray line bug to limit us to DC on newer hardware to lower the risk of problems.

Attachment 9133067 [details] addressed the problem for me.
:jrmuizel, can you check if the patch addresses the problem for you?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8b44dbb1c212aadc38a79ae8fbbb7c1531f4072

https://hg.mozilla.org/mozilla-central/rev/9a7c2d7af71f

Sotaro, Jeff, should we request beta uplift for this now, or does it need to wait a couple days in nightly first?

Comment on attachment 9133067 [details]
Bug 1620491 - Disable native compositor when hardware stretching is not supported

Beta/Release Uplift Approval Request

• User impact if declined: It could cause a gray line separating tab like Bug 1618370 when hardware stretching is not supported and "Desktop resolution" and "Active signal resolution" are different.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change just disable WR native compositor when hardware stretching is not supported.
• String changes made/needed: none

(In reply to Glenn Watson [:gw] from comment #17)

Sotaro, Jeff, should we request beta uplift for this now, or does it need to wait a couple days in nightly first?

I just requested the uplift.

Comment on attachment 9133067 [details]
Bug 1620491 - Disable native compositor when hardware stretching is not supported

WR/DC fix, approved for 75.0b5

https://hg.mozilla.org/releases/mozilla-beta/rev/7f042e82ef7f

== Change summary for alert #25410 (as of Sun, 15 Mar 2020 11:42:29 GMT) ==

Improvements:

24% tscrollx windows10-64-shippable-qr opt e10s stylo 1.12 -> 0.85
10% tart windows10-64-shippable-qr opt e10s stylo 2.94 -> 2.64

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25410

Results from running some tests from Jeff:

At native (3840x2160):

dev@DESKTOP-WIN10 MINGW64 ~/Downloads
$ ~/display.exe
scaling: 5
target res 3840 2160
source res 3840 2160
target: modeInfoIdx: 0 desktopModeInfoIdx: 0 targetModeInfoIdx: 0 source: 1
scaling 1
28
10
3840 2160
3840 2160

At 2048x1152

dev@DESKTOP-WIN10 MINGW64 ~/Downloads
$ ~/display.exe
scaling: 5
target res 3840 2160
source res 3840 2160
target: modeInfoIdx: 0 desktopModeInfoIdx: 0 targetModeInfoIdx: 0 source: 1
scaling 1
28
10
3840 2160
2048 1152

Berts results are the same:

scaling: 5
target res 3840 2160
source res 3840 2160
target: modeInfoIdx: 0 desktopModeInfoIdx: 0 targetModeInfoIdx: 0 source: 1
scaling 1
28
10
3840 2160
2048 1152