Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329569 - Inconsistent use of NSColorSpaces in Cocoa SWT
Summary: Inconsistent use of NSColorSpaces in Cocoa SWT
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.7   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: 3.7 M4   Edit
Assignee: Scott Kovatch CLA
QA Contact: Silenio Quarti CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-05 13:34 EDT by Scott Kovatch CLA
Modified: 2011-03-28 23:07 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Kovatch CLA 2010-11-05 13:34:42 EDT
The change for 325687 introduced a regression in drawing foreground and background colors on Controls because we were inconsistent in the use of device vs. calibrated colors.

We need to switch to NSCalibratedColorSpace everywhere, but this will trigger JUnit test errors on OS X 10.5 only (snow leopard is fine). We'll need to revisit the failing tests to see if we can either work around the OS bug or adjust the tests.
Comment 1 Scott Kovatch CLA 2010-11-05 13:58:05 EDT
The changes for GC and Image were checked in. I'm looking at compatible ways of fixing this on 10.5. I'm thinking the work I started in 272592 will be helpful here.
Comment 2 Scott Kovatch CLA 2010-11-05 16:51:46 EDT
I'm going to take care of this with conditional code. Pre-10.6 we use the device-based NSColor calls; otherwise use calibrated-based calls.

NSBitmapImageRep and related code was completely rewritten in 10.6, so it doesn't surprise me that we're hitting this, but I also don't think it's worth a big rewrite of the Image code to fix it.
Comment 3 Scott Kovatch CLA 2010-11-05 19:19:26 EDT
I narrowed the problem down to GC.checkFill(), where it sets the background fill color. It looks like there's one specific combination of new Image(int, int), setBackground, and getImageData() that triggers the bug on 10.5, and the only workaround is to use device RGB values in that one situation. 

All other places in the code can go back to using NSCalibratedRGBColorSpace or NSColor.colorWithCalibratedRed(). Given the special circumstances needed to trigger the problem, and that it's only on 10.5, I now consider this bug fixed.
Comment 4 Scott Kovatch CLA 2010-11-08 12:27:57 EST
*** Bug 329641 has been marked as a duplicate of this bug. ***
Comment 5 Andre Berg CLA 2011-01-04 01:10:30 EST
Hi,

I recently had to update my EGit installation and because I couldn't find the latest version through Check for Updates, I added the Eclipse Staging Area site from which I updated EGit to 0.10.1, as well as taking updates for Mylyn. I noticed it also wanted to update Eclipse SDK from 3.6.1 to 3.7, so I let it do that. 

Upon restarting I noticed that all colors used to render the Eclipse main window have gone too bright. Not just colors for images or icons but also colors used in the tab gradients. 

Searching for bugs I found this one, but now I don't know if the Eclipse version that has the fix for this bug is just not available yet or if the bug was somehow re-introduced again.

I have uploaded some screenshots which you can find at 

http://www.bergmedia.de/remote/eclipse/bugzilla/329569/eclipse37.png
http://www.bergmedia.de/remote/eclipse/bugzilla/329569/eclipse361.png
Comment 6 Andre Berg CLA 2011-01-04 01:13:41 EST
Sorry, I should mention I am on Mac OS X 10.6.4.
Comment 7 Scott Kovatch CLA 2011-03-28 23:07:17 EDT
(In reply to comment #5)

> Upon restarting I noticed that all colors used to render the Eclipse main
> window have gone too bright. Not just colors for images or icons but also
> colors used in the tab gradients. 
> 
> Searching for bugs I found this one, but now I don't know if the Eclipse
> version that has the fix for this bug is just not available yet or if the bug
> was somehow re-introduced again.

The colors that were used in 3.6.2 were saved in the device color space, but after the update to 3.7 they are now being interpreted as calibrated colorspace colors, so they may look slightly wrong. That's an unfortunate side effect of this change because we can't tell how to interpret any RGB colors that may have been written out to preferences.