1181745 - Window doesn't redraw correctly when switching between HiDPI and LowDPI displays with hardware acceleration off and OMTC on

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Rosser Schwarz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

Steps to reproduce:

Launch Firefox on internal HiDPI screen 
Connect external LowDPI monitor
Close laptop/enter clamshell mode

(Also happens in reverse — launch on LowDPI screen; open laptop lid)

Before upgrading to 39.0, issue was intermittent. Since upgrading, it's 100% reproducible.


Actual results:

Browser window doesn't redraw at new pixel density (when going from LowDPI to HiDPI, viewport is cropped; when going from HiDPI to LowDPI, old viewport only takes up a small portion of current viewport)


Expected results:

Window should have redrawn to new pixel density

Comment 1

[Rosser Schwarz]

Attachment: Switching from LowDPI to HiDPI

Comment 2

[Rosser Schwarz]

Attachment: Switching from HiDPI to LowDPI

Comment 3

[Rosser Schwarz]

Before upgrading to 39.0, refreshing page would correct the undesired behavior when it occurred. After upgrading, only quitting/restarting seems to work.

Comment 4

[Rosser Schwarz]

Opening a new window after switching displays results in a correctly-sized window.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> Steps to reproduce:
>
> Launch Firefox on internal HiDPI screen 
> Connect external LowDPI monitor
> Close laptop/enter clamshell mode

You're missing some steps here.  Please elaborate.

You reported this bug on OS X 10.9.5.  It that also where you see the problem?

Comment 6

[Rosser Schwarz]

Correct; I see the issue on 10.9.5. Upgrading isn't an option on this machine, but I can probably find some 10.10.x machines to test on, in case it's an OS version-specific issue.

What further information or steps do you need to repro?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> What further information or steps do you need to repro?

You tell me.

For example, what do you need to do after step 3 to see the bug?

I'll ask other questions as you provide more information.

The reason I'm a bit testy is that I've had about 10 similar reports, none of which I've been able to reproduce.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

And no, it's not that I don't believe you (and the other reporters).  But this kind of bug is almost impossible to fix without being able to reproduce it.

Comment 9

[Rosser Schwarz]

> For example, what do you need to do after step 3 to see the bug?

Nothing. When the window shows up on the other display from the one on which it's launched, it's rendered incorrectly.

I understand you can't do much without being able to repro the bug, and I'd like to help you get there, but I'm not sure what else you're looking for. The steps I described (launch a browser, change displays) are really all it appears to take for me to reproduce the behavior.

I'll try to work with a couple of people at the office tomorrow to see if I can reproduce the behavior on their systems and report the results and their configs. Please advise me of any specific things you think it would be helpful to try, or to check for, in doing that, and I'll happy to do what I can to accommodate.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

> Nothing. When the window shows up on the other display from the one
> on which it's launched, it's rendered incorrectly.

This information is helpful.

But I just tried your STR ... and didn't see the bug.

I tested in FF 39 on OS X 10.9.5 (on a Retina MacBook Pro).

If you do test around your office, please let us know your results.

Here are a couple of things that might make a difference (and have in
unrelated bugs):

How the displays are arranged in Displays : Arrangement.

Which display contains the menu bar (internal or external).

Finally (and as a last resort), try rebooting your computer.  In my
experience, the client versions of OS X (as opposed to the server
versions) get flakier the longer you run them -- especially if they go
unrebooted for days or weeks.  I've seen any number of bafflingly
weird problems cleared up be rebooting :-)

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Another thing:

You should try testing in Safe Mode (which disables all your extensions and may change your graphics settings) -- see if that makes a difference.  Do this before rebooting your computer :-)

You can turn on Safe Mode by choosing Help : Restart with Add-ons Disabled.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Low and behold, I see the problem myself in Safe Mode!

I'll check to see what the crucial factor is.

Comment 13

[Rosser Schwarz]

The displays are arranged so the internal (HiDPI) display is primary, and has the menu bar when the laptop is open. When it's closed/in clamshell mode (which is what triggers the redraw, as the windows are moved between the internal and external displays), the external is the only display.

This happens on freshly-launched browser windows on a freshly rebooted (well, the night before) machine.

The also issue appears for me in Safe Mode.

Please let me know if there's anything else I can do to help dx or test.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> I'll check to see what the crucial factor is.

For me it's the "use hardware acceleration when available" setting in Preferences : Advanced : General.  When it's checked/on (as it is by default), I don't see the bug.  When it's off I do (using the STR from comment #0).

I'll be looking for a regression range.

Rosser, do you have "use hardware acceleration when available" off?

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Note that when you change your "use hardware acceleration when available" setting, you'll need to restart Firefox for the change to take effect.

Comment 16

[Rosser Schwarz]

Yes, my "Use hardware acceleration when available" is off. Enabling it appears to fix the issue for me as well.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Finding the regression range for this bug is made *very* difficult by the fact that, with hardware acceleration off, graphics display simply stopped working between the following builds (inclusive).  The browser window was always simply a blank white page.

firefox-2015-04-01-03-02-04-mozilla-central
firefox-2015-04-16-03-02-09-mozilla-central

Comment 18

[Steven Michaud [:smichaud] (Retired)]

However, if you turn OMTC off (by setting layers.offmainthreadcomposition.enabled to false), graphics display works again in the range from comment #17.

And this bug stops happening -- even in today's mozilla-central nightly.

So this bug happens when hardware acceleration is off (a non-default setting) and OMTC is on (the default setting).

Comment 19

[Steven Michaud [:smichaud] (Retired)]

Given what I just found, I'm reclassifying this bug as a graphics bug.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

David, you did a lot of work on a similar bug (bug 1125325).

Do you have any ideas what to do here?

Comment 21

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #17)

On all the m-c nightlies I tested with, I turned e10s off -- e10s requires hardware acceleration.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Note that this bug's regression range is somewhere in the (impossibly large) range from comment #17.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

Testing on my Retina MacBook Pro, I see this bug on OS X 10.7.5 and 10.9.5, but not 10.10.4.  (My MBP doesn't have an OS X 10.8.5 partition to test with.)

Comment 24

[Steven Michaud [:smichaud] (Retired)]

Since this bug happens only with a non-default setting (hardware acceleration off), I'm inclined to think it's not very important.  I don't think we should spend a lot of time on it.

But if it turns out to have an easy fix ...

Comment 25

[Steven Michaud [:smichaud] (Retired)]

Thinking more about this, I realized that, though FF 39 is effected, the regression actually took place (on the trunk) on the 40 branch.  So the regressing patch must have been uplifted.  In fact it was uplifted to aurora (the 39 branch) from trunk (the 40 branch).

The aurora branch regression range is:

firefox-2015-04-23-00-40-12-mozilla-aurora
firefox-2015-04-24-00-40-08-mozilla-aurora

https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=ddebce1c80aa&tochange=d3e683848887

From this it's pretty clear that the following was the regressing patch:

https://hg.mozilla.org/releases/mozilla-aurora/rev/d3e683848887

 Bug 1151644 - Don't disallow the basic compositor backend. r=jrmuizel, a=lmandel
author	Nicolas Silva <[e-mail]>
	Thu, 16 Apr 2015 07:57:00 +0200

Comment 26

[Steven Michaud [:smichaud] (Retired)]

So the patch that triggered this bug also fixed the problem I described in comment #17.  So no, I don't expect we can back out the patch for bug 1151644.

My question to you, Nicolas, is do you have any idea what's going on here?  I suspect the patch for bug 1151644 somehow reduced the number or changed the timing of screen updates -- so that this bug's glitches go from temporary to permanent.  Having OMTC on (or rather changing it from off to on) also seems to have that effect.

Does that idea make sense to you?

Once again, I doubt we should spend much time on this bug.  But if we can find (or stumble upon) an easy fix ...

Comment 27

[Nicolas Silva [:nical]]

(In reply to Steven Michaud [:smichaud] from comment #26)

> My question to you, Nicolas, is do you have any idea what's going on here? 

I am switching between too many things at the moment so I need to focus on other stuff before I come back to this bug and give you a satisfactory answer.
My first uneducated thought when glancing at this is that BasicCompositor does not do the right thing when switching between low and high res screens on mac, but I don't know what code does this job for the gl compositor (Markus do you?).

Keeping the needinfo as a reminder.

Comment 28

[adam]

I experience this with 42.0a2 (2015-09-01) as well on Fedora 22. They just added HiDPI switching automatically, so when I plug in a monitor which isn't hidpi it switches to LowDPI. I open firefox in LowDPI mode. When switching back to HiDPI (by unplugging the monitor) the page renders like "Switching from LowDPI to HiDPI" image. New tabs open properly, refreshing old tabs does not fix. If switching back to LowDPI when experiencing this rendering issue, the old tabs render properly (but the tabs opened in HiDPI mode are very large which is same behavior reported above).

Comment 29

[Steven Michaud [:smichaud] (Retired)]

> They just added HiDPI switching automatically

I don't understand what this means.  Can you paste in a link to a reference that explains it?

Comment 30

[adam]

Previous versions didn't automatically modify "Window scaling" when you were connecting/disconnecting different DPI screens. There is still only one "Window scaling" value for the whole desktop regardless of mix of HiDPI vs LowDPI screens. It seems to default to "Window scaling" = 1 when any LowDPI screen is connected.

You can also reproduce this behavior by modifying "Window scaling" value in Gnome Tweak Tool from 1 to 2 and back to 1.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

> Previous versions

Of Gnome, I assume.

So far this bug has been entirely about problems on OS X.  You should open a new bug (still under Core : Graphics) about this problem in Gnome.

Comment 32

[u279076]

Does this bug still reproduce?

Comment 33

[Markus Stange [:mstange]]

I'm pretty sure this is fixed now.