616232 - Unified toolbar/titlebar has mismatched gradient on secondary monitor

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Stephen Horlander [:shorlander]]

Attachment: Titlebar/Toolbar Color Mistmatch

Moving the Firefox window to another monitor with a different display profile causes a visible mismatch between the toolbar and the titlebar.

Sometimes it sticks when moving back to the primary display and other times it reverts to the correct appearance.

STR:
1) Move Firefox window to secondary monitor with a different display profile
2) Move back to main monitor

This is the only way I can reproduce this problem. Limi reports that it happens on his monitor with no secondary display connected. That may be a separate problem that I could not see on three different Macs.

Comment 1

[Markus Stange [:mstange]]

I'm surprised that this happens even in tabs-on-bottom mode.

Does this bug also occur when hardware acceleration is disabled?

Comment 2

[Stephen Horlander [:shorlander]]

(In reply to comment #1)
> I'm surprised that this happens even in tabs-on-bottom mode.
> 
> Does this bug also occur when hardware acceleration is disabled?

No it doesn't occur when hardware acceleration is disabled.

Comment 3

[Markus Stange [:mstange]]

Any idea what we can do about this?

Comment 4

[Joe Drew (not getting mail)]

I'd bet this has to do with colour correction being different on a different monitor. I don't think this is a bad enough issue to block, but I'd happily take a patch.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

10.5 or 10.6?

Comment 6

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #5)
> 10.5 or 10.6?

10.6.

Comment 7

[Markus Stange [:mstange]]

The 10.6 release notes at http://developer.apple.com/library/mac/#releasenotes/cocoa/appkit.html talk about a new NSWindow method called setDisplaysWhenScreenProfileChanges. Maybe we just need to call that.

Comment 8

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Markus, have you had a chance to give this a try? If you don't have the time, perhaps you could point me in the right direction and I could give this a go?

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

I hooked up the handling for that stuff but didn't know what do from there. I got the call from cocoa but wasn't sure what to do with it... not sure if there's anything that just says "correct colors").

On further investigation and ideas from Dolske, it looks like we're already making adjustments to color, so perhaps we're just doing that wrong. Comparing side by side with Safari, it looks like our toolbar is the right color, but our titlebar isn't. (We have other slight color differences too but whatever).

Anyway... looking more at nsNativeThemeCocoa::DrawUnifiedToolbar, it looks like we attempt to do color space correction by using CGColorSpaceCreateDeviceRGB, but according to http://developer.apple.com/library/mac/#documentation/graphicsimaging/Reference/CGColorSpace/Reference/reference.html that only ever returns the generic color space...
> In Mac OS X v10.4 and later, this color space is no longer device-dependent and is replaced by the generic counterpart—kCGColorSpaceGenericRGB—described in “Color Space Names”. If you use this function in Mac OS X v10.4 and later, colors are mapped to the generic color spaces. If you want to bypass color matching, use the color space of the destination context.

Comment 10

[Timothy Nikkel (:tnikkel)]

Do we just need to redraw everything or do we need to recreate device contexts or some such?

Comment 11

[Markus Stange [:mstange]]

I haven't had a chance to look at this yet, no.

When the bug happens, does unfocusing and refocusing the window make it go away? 

(In reply to comment #9)
> Comparing
> side by side with Safari, it looks like our toolbar is the right color, but our
> titlebar isn't.

And comparing to a Firefox window that hasn't been moved between screens?

Comment 12

[Markus Stange [:mstange]]

Attachment: test patch

This was the change I was thinking of in comment 7. Does it have any effect?

Comment 13

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #11)
> I haven't had a chance to look at this yet, no.
> 
> When the bug happens, does unfocusing and refocusing the window make it go
> away?

No. The toolbar still has the wrong colors when the window is unfocused. Refocusing doesn't fix it.

> (In reply to comment #9)
> > Comparing
> > side by side with Safari, it looks like our toolbar is the right color, but our
> > titlebar isn't.
> 
> And comparing to a Firefox window that hasn't been moved between screens?

On the second display, the titlebar is correct, the toolbar isn't. (My comment in #9 was confusing, that part you quoted was actually about our correct windows).

(In reply to comment #12)
> Created attachment 516234 [details] [diff] [review]
> test patch
> 
> This was the change I was thinking of in comment 7. Does it have any effect?

No. I have that as well in my patch (I also added handling of windowDidChangeScreenProfile but didn't know what to do in there).

(In reply to comment #10)
> Do we just need to redraw everything or do we need to recreate device contexts
> or some such?

I'm guessing we might need to recreate device contexts... hiding/showing the window, covering/uncovering the window doesn't result in us correcting the color

FWIW, with today's nightly I can no longer reproduce... Can anybody else?

Comment 14

[Timothy Nikkel (:tnikkel)]

(In reply to comment #13)
> (In reply to comment #10)
> > Do we just need to redraw everything or do we need to recreate device contexts
> > or some such?
> 
> I'm guessing we might need to recreate device contexts... hiding/showing the
> window, covering/uncovering the window doesn't result in us correcting the
> color

We might just be showing the retained data still in those cases.

Comment 15

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to comment #14)
> We might just be showing the retained data still in those cases.

Is there a way to flush that?

BTW, I was misled about not being able to reproduce. Still happens (just wasn't at the time).

Comment 16

[Timothy Nikkel (:tnikkel)]

Doing something like this code http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6080 would be a good way to test that.

Comment 17

[TGOS]

Since 10.8 I have this issue on all my monitors as soon as I calibrate them; I don't have to move the window between two monitors, I have the problem even on my a Mac which only has a single monitor connected. The colors are okay if I use the standard color profile of the monitor, the sRGB or the Adobe RGB color profile. If I use the Generic RGB Profile or any other profile I created, the colors are wrong as in the screenshot attached to this bug.

I have a Spyder4Express calibration device, as the default color profiles of most monitors are horrible (bad gamma, bad color temperature, etc.) I calibrate my monitors using dispcalGUI, an OpenSource UI for Mac, Linux and Windows, that bases on Argyll CMS, an OpenSource command line calibration tool, also available for Mac, Linux, and Windows. These tools are much better than the software shipped with most devices (offer more options, allow more fine tuning of the profile, etc.)

And I have to disagree with Paul: On my Mac the titlebar seems to have the right color (exactly like the one of other apps, e.g. Safari), it's the toolbar that seems wrong IMHO (it is too bright).

Just like mentioned earlier, the issue goes away if I disable hardware acceleration. On 10.7 I had no such issue, even though I always had hardware acceleration enabled, yet I cannot tell, if it was really enabled on my system (maybe the graphics adapter drivers on 10.7 didn't offer a necessary feature and thus hw-accel hasn't being used). 

How strong the issue is visible depends on how "bad" the default profile for the monitor has been. It seems like the titlebar is correctly color corrected according to profile, yet anything below isn't. If the profile is close to the default profile, titlebar and toolbar look very similar, since the color correction of the titlebar has little effect on its colors. However, one of my monitors has a horrible default profile and here the difference is even stronger than in the attached screenshot.

For testing purposes, I could offer the following: I could create a calibration profile which is intentionally wrong and completely "distorts" all colors on the monitor. You could install it and verify that your whole OS X desktop and all windows have completely wrong colors. Ideally Firefox should now also have those bad colors inside its window, regardless if hw-accel is enabled or not. Currently I think that with hw-accel enabled, the colors inside the Firefox window will actually look "right" and in that case, this would mean they are "wrong" (haven't tried it yet, I plan on testing that next week).

BTW, I don't think that bug 676241 is the solution to this problem. I don't think that drawing the titlebar in OpenGL is a good idea to start with. Window controls should be done by the operating system/desktop manager, not by the app itself. That way they will always look right to users, regardless how the user has configured/tuned his/her system and regardless what Apple plans for the future.

Comment 18

[Markus Stange [:mstange]]

(In reply to TGOS from comment #17)
> For testing purposes, I could offer the following: I could create a
> calibration profile which is intentionally wrong and completely "distorts"
> all colors on the monitor.

That would be helpful, yes.

> You could install it and verify that your whole
> OS X desktop and all windows have completely wrong colors. Ideally Firefox
> should now also have those bad colors inside its window, regardless if
> hw-accel is enabled or not. Currently I think that with hw-accel enabled,
> the colors inside the Firefox window will actually look "right" and in that
> case, this would mean they are "wrong" (haven't tried it yet, I plan on
> testing that next week).

Sounds plausible.

> BTW, I don't think that bug 676241 is the solution to this problem.

OK, do you have a different idea for how to get identical color correction in both areas of the window?

Comment 19

[TGOS]

Attachment: Monitor profile with a touch of green

This profile should give your monitor a strong touch of green. I had expect that it will apply to everything except for Firefox's window content (with hw-accel enabled), yet I stand corrected. The window content looks as "greenish" as the rest.

Comment 20

[TGOS]

Attachment: Monitor profile with a rather dark touch

This monitor profile partially enhances the contrast of the monitor (to the extreme) and gives a rather dark touch. Using this profile I can see the difference between the title bar and the toolbar much stronger than with my real profile (created with a calibration device).

Comment 21

[TGOS]

I took a look at the source code; unfortunately the relevant source code is spread across so many files, so it's hard to get an overview how the code path is different depending on the fact if hw-accel is enabled or not. So far I found nothing suspicious. 

I'm taking a shot into the dark here, but could it be that Firefox applies color correction to images (or other RGB(A) data) prior to loading them into textures? Since it seems that the system automatically applies the active color profile to all OpenGL rendering when it gets displayed on the screen and when applying color correction to texture data, the pixels might get color corrected twice (they are over corrected). Well, just clutching at any straw here.

Comment 22

[Markus Stange [:mstange]]

(In reply to TGOS from comment #21)
> I'm taking a shot into the dark here, but could it be that Firefox applies
> color correction to images (or other RGB(A) data) prior to loading them into
> textures?

It does, but I'm not sure about the details. It can be disabled by setting gfx.color_management.mode to 0 in about:config.

Comment 23

[TGOS]

(In reply to Markus Stange from comment #22)
> It does, but I'm not sure about the details. It can be disabled by setting
> gfx.color_management.mode to 0 in about:config.

Tried to disable it, yet it has no effect on the issue described here. Are you sure this setting also applies to UI graphics? The description of this option sounds to me as if it only applies to images loaded from the web.

Comment 24

[Benoit Girard (:BenWa)]

gfx.color_management.mode is applied to image decoding but it doesn't have an impact on the windows's CGContext used for the titlebar. I think the best solution here is to use only Opengl to draw the window.

Comment 25

[TGOS]

(In reply to Benoit Girard (:BenWa) from comment #24)
> gfx.color_management.mode is applied to image decoding but it doesn't have
> an impact on the windows's CGContext used for the titlebar.

That's what I suspected; so the question remains if color correction is applied to UI images prior to loading them into textures. If that is the case, this may be the cause of the problem.

> I think the best
> solution here is to use only Opengl to draw the window.

But then everything, including the title bar, will have wrong colors. Right now the issue is, that the title bar has the *right* color, yet the toolbar has the wrong color. Drawing everything in OpenGL will make the issue away, yet it will do so by making everything wrong, including the title bar. How can the solution to wrong colors be making the only correct ones also incorrect?

Comment 26

[Benoit Girard (:BenWa)]

A solution is to perform the color conversion to the monitor space after we're composited the final frame as a post processing step. See bug 700927 for my progress on that. The idea is to compute the transformation lookup tables and upload it to a 3D texture and use a trivial shader.

Comment 27

[TGOS]

Attachment: Proof that titlebar is right, yet all other colors are wrong

On the left side of the image is Fx without hw-accel disabled, on the right side with hw-accel enable. This clearly disproves that the titlebar is the issue, since the window titlebar looks identical in either case. The issue is "anything *but* the titlebar". Even the *white canvas* of the blank window has the wrong color (the white is a lot more grayish than it should be); everything is quite a bit too dark. However it depends on the color profile chosen, with another profile everything is too bright.

Comment 28

[Benoit Girard (:BenWa)]

Yes I agree. We don't color manage our OpenGL view and we should.

Comment 29

[TGOS]

(In reply to Benoit Girard (:BenWa) from comment #28)
> Yes I agree. We don't color manage our OpenGL view and we should.

Do you have any idea where the "color management" takes place when hw-accel is disabled yet is skipped when it is enabled? I'm having a really hard time to find this piece of code. Today I finally managed to build Fx from source (for the first time in years!) and I made some changes to a couple of suspicious code lines but without any success.

I saw your other bug and how you are trying to add color management to OpenGL, yet what I don't see is where the color management takes place if OpenGL is not being used. 

Or to put it in other, maybe simpler words: Where would I have to "break" Firefox if my goal was to make Firefox display everything *equally wrong* when hw-accel is *not* being used? Any idea?

Comment 30

[Benoit Girard (:BenWa)]

Quartz perform the color management for the CGContext used by the window while when we drawing using OpenGL no color management is applied:

http://developer.apple.com/library/mac/#technotes/tn2035/_index.html

I don't know where you would break if there no color management since nothing is done I don't see a logical break point. You can break when we draw to the CGContext used by the title bar (and the app if we're not accelerated) and you'll find that the drawing operation are calling ColorSync to color manage the CGContext.

Comment 31

[TGOS]

(In reply to Benoit Girard (:BenWa) from comment #30)
> Quartz perform the color management for the CGContext used by the window
> while when we drawing using OpenGL no color management is applied

So you are basically saying that Firefox doesn't explicitly do anything to perform color correction, it's performed implicitly by the system. Yet the system does not perform color correction for OpenGL content, Firefox has to perform it manually if it is desired?

In that case, will a fix for bug 700927 only apply to web content displayed or to all UI elements, including window background, toolbars, tabs, address bar, etc.? Since if it applies to everything, a fix for this bug will automatically fix this issue as well, so we should probably make this issue depend on bug 700927 and close it as soon as it has been fixed.

Comment 32

[Markus Stange [:mstange]]

Bug 676241 fixes this in the case when we draw window contents in the title bar. For now this is only the case for the main browser window when a lightweight theme is used, or in Private Browsing windows (which draw the purple indicator in the titlebar), or as soon as Australis lands which puts the tabs into the titlebar.
For other windows we don't extend the OpenGL context into the titlebar yet.

Comment 33

[Gregory Pappas [:gregp]]

Closing per comment 32