4

Update

This problem disappeared after upgrading from Mountain Lion to Mavericks, while also updating Emacs from 23.4 to 24.3.

End-update

With a .emacs file containing

(set-foreground-color "white")
(set-background-color "black")

(setq mouse-wheel-scroll-amount '(1 ((shift) . 1) ((control) . nil)))
(setq mouse-wheel-progressive-speed nil)

as I scroll up or down with the reduced step, I see the strange patterns

vertical lines

Magnifying one of the patterns reveals

magnified one vertical line

This problem has been present in Emacs 22, 23, and now 24 for several versions of OSX—up to and including Mountain Lion. Is it a known rendering bug? Is there a fix?

Neither the suggestion to modify fringes nor linum works for me. Where else can I look?

If I use the default white background and black foreground, these lines either do not appear or are imperceptible (to me).

What is most pesky about this problem is that redrawing (C-l) does not result in clean text.

Community
  • 1
  • 1
Calaf
  • 10,113
  • 15
  • 57
  • 120
  • I'm guessing this is an issue with font rendering. Try changing to a different font and see if you have issues. Are you using emacs in a terminal? – Randy Morris May 12 '13 at 22:28
  • You are probably right. I can't find another font where the problem appears. This happens only with Apple's default Monaco fonts. Indeed they happen with all sizes of Monaco. But I certainly don't wish to sacrifice a font as suitable for programming, and one that renders as rapidly as, Monaco. – Calaf May 12 '13 at 22:42
  • I made a few more trials. The problem appears with at least one other font: Menlo. – Calaf May 12 '13 at 23:03
  • Interesting that both of these are Apple fonts. I'm not sure how to help you. Are you running emacs in a terminal or are you running the gui? – Randy Morris May 12 '13 at 23:07
  • I'm running basic emacs (http://emacsformacosx.com/) in a standalone window. – Calaf May 12 '13 at 23:22
  • Mouse can be controlled inside system preferences also. Have you tried removing your mouse settings from E-macs? Alternatively, have you tried a nightly build from the same source? There is also Aquamacs you could try. – lawlist May 13 '13 at 11:55
  • I just tried Aquamacs. It displays an identical problem. The root of the problem may be the default half-page increment in emacs. There is no reason to hang on to a relic of terminals with expensive screen refresh. When a longer function does not fit, it is very handy to scroll by a handful of lines until it does. If I increase the increment to, say, 5 lines, the problem still appears, but every fifth line. – Calaf May 13 '13 at 13:14
  • I have seen this problem, too. But it doesn't bug me so much; when I C-L, I get a clean display. anyway it's only a minor distraction for me. – Cheeso May 14 '13 at 04:34
  • @Cheeso I also have lived with this "slight imperfection" for years, but I've never been able to shake it off. It's always front in my mind that there is a flaw in the display, and, by extension, in my program. – Calaf May 14 '13 at 14:49

1 Answers1

1

The problem is related to the interaction between OS X's LCD Font Smoothing algorithm and the algorithm that emacs uses to implement scrolling.

The figure below shows font smoothing turned off (left) and on (right). You will find this setting in System Preferences \ general. In both cases I scrolled the program by one line. When OS X draws the "@" with font smoothing turned on, it does not only use the pixels dedicated to the "@" but also uses the blue pixels of the adjacent (blank) character.

When emacs scrolls, it only modifies the characters that it believes need to be modified. If the character is blank and will remain blank after scrolling, it does not modify it. This optimization remains valid in 2013. In other words, testing that two characters are blank is still cheaper than drawing one character. But this optimization is hardly necessary today, and it results in the buggy display.

If the hypothesis above holds, the sequel question becomes whether one can turn off the optimization. Is it possible to ask emacs to redraw the full screen at each scroll or to at least redraw characters that remain blank if they were adjacent to a non-blank character.

Font smoothing off (left) and on (right)

One could of course simply turn off font smoothing. The magnified image may even suggest that the non-smoothed image is better. In practice, when the fonts appear in their natural (unmagnified) size, smoothing makes the characters far more legible, eliminating the need to use larger fonts.

The pattern on either side of "c();" in the image below is consistent with the bug. OS X uses blue pixels on the left side and red/tan pixels on the right (possibly this is related to the RGB pattern on the display). The vertical lines left over when scrolling are either blue or red/tan/brick, depending on whether they have dropped out of the left or right side of scrolled characters.

blue hints on the left; red hints on the right

Update

The problem is now solved in this nightly. The magnified c(); produced by Emacs 24.3.50.1 shows that the font smoothing remains identical to that produced by Emacs 24.3.1. But the output is not identical. There is at least one extra horizontal line of pixels between each two lines of text.

Calaf
  • 10,113
  • 15
  • 57
  • 120