Separator color comes out wrong
eriksvedang opened this issue · comments
When I adjust the color of various parts of the mode-line, the colors of the separators don't match up perfectly. It seems as if they are always a bit too bright..?
(set-face-attribute 'powerline-active1 nil
:foreground "gray20"
:background "gray90")
(set-face-attribute 'powerline-active2 nil
:foreground "gray95"
:background "gray60")
Leads to the following look:
Please post your Emacs info from
M-x version
GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21) of 2015-04-10 on builder10-9.porkrind.org
(setq ns-use-srgb-colorspace nil)
This happens to me when I have transparency enabled with iTerm on OS X. Disabling transparency fixed it for me :)
Hmm, I'm using the build from emacsformacosx.com, no iTerm.
Use the setting I provided. It's an issue with SRGB and pixmap rendering (which doesn't use a colorspace)
Sorry, missed your comment. That worked perfectly, thanks a lot for the help!
Also an interesting point to make is that, after loading your config with
(setq ns-use-srgb-colorspace nil)
and then you reload the same config with (setq ns-use-srgb-colorspace t)
appended, it fixes itself until a screen resize. Might be worth while to check out for a bug fix?
Hi,
I was looking super quickly at how the separators are being generated and they are done programmatically. The target rendering colourspace is know, i.e. sRGB, and the pixmap rendering path is known, I'm unclear on the reasons behind the discrepancies in colour rendering of those elements, especially if the input colours of both rendering paths are known. There should be a way to reconcile them to match gracefully instead of deactivating sRGB support.
Cheers,
Thomas
I just came across this related post: http://emacsredux.com/blog/2014/01/11/a-peek-at-emacs-24-dot-4-srgb-colours-on-os-x/, which lead me to that thread: http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html
Interesting discovery that one, @KelSolaar. Looking at the latest version of nsterm.m
in the GNU Emacs source it would appear that the issue has - sort of - been addressed:
/* ==========================================================================
NSColor, EmacsColor category.
========================================================================== */
@implementation NSColor (EmacsColor)
+ (NSColor *)colorForEmacsRed:(CGFloat)red green:(CGFloat)green
blue:(CGFloat)blue alpha:(CGFloat)alpha
{
#if defined (NS_IMPL_COCOA) \
&& MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
if (ns_use_srgb_colorspace
#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
&& [NSColor respondsToSelector:
@selector(colorWithSRGBRed:green:blue:alpha:)]
#endif
)
return [NSColor colorWithSRGBRed: red
green: green
blue: blue
alpha: alpha];
#endif
return [NSColor colorWithCalibratedRed: red
green: green
blue: blue
alpha: alpha];
}
- (NSColor *)colorUsingDefaultColorSpace
{
/* FIXMES: We're checking for colorWithSRGBRed here so this will
only work in the same place as in the method above. It should
really be a check whether we're on macOS 10.7 or above. */
#if defined (NS_IMPL_COCOA) \
&& MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
if (ns_use_srgb_colorspace
#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
&& [NSColor respondsToSelector:
@selector(colorWithSRGBRed:green:blue:alpha:)]
#endif
)
return [self colorUsingColorSpace: [NSColorSpace sRGBColorSpace]];
#endif
return [self colorUsingColorSpaceName: NSCalibratedRGBColorSpace];
}
@end
This explains why @jasonm23's suggestion hides the symptom. It also shows that it will depend on how your Emacs executable was compiled. It would thus be interesting to hear from someone who has compiled their Emacs with both, MAC_OS_X_VERSION_MAX_ALLOWED
and MAC_OS_X_VERSION_MIN_REQUIRED
being greater than 1070.
For others reading (setq powerline-image-apple-rgb t)
turns out to work better, I'm using emacs-plus installed with brew.
For others reading
(setq powerline-image-apple-rgb t)
turns out to work better, I'm using emacs-plus installed with brew.
Bummer! Why didn't I figure that one out myself? Too obvious, probably... 😞
Many thanks, @zzantares !