# Colored marks appearing in notebook input text?

Bug introduced in 10, persisting through 11.0.1 or later

What is the causing these colored marks to appear in my Mathematica notebook? I'm particularly annoyed with the black ovals that occasionally obscure parts of the input as I'm typing:

I have also observed the appearance of rectangular blue marks with similar behavior:

$Version --> 10.0 for Microsoft Windows (64-bit) (September 9, 2014) $System --> Microsoft Windows (64-bit)

Are these marks related to syntax-highlighting? Has anyone else experienced this behavior where what look like highlighting marks become permanent fixtures in the notebook, and do not scroll with the contents?

• I have seen these black ovals too. I don't know if they are tied to syntax highlighting however. You can turn off "automatic syntax highlighting" from the menu Edit > Preferences... > Appearance. Consider perhaps making this question primarily about the bug you are experiencing. – Mr.Wizard Oct 26 '14 at 1:23
• I've just started getting these. Presumably I've turned something on by accident. – Ymareth Nov 10 '14 at 16:19
• I suggest adding version 10 tag. – Johu Jun 18 '15 at 21:52
• Unfortunately this problem is still with us in mid-2015: see the more recent Floating highlighting bug. – MarcoB Jun 19 '15 at 3:12
• @MichaelE2 Seems fixed. I added the tag to my post as well. – Johu Aug 4 '15 at 15:29

Various folks at WRI have spent a decent amount of time running this to ground, and I now think it's well understood thanks to a considerable team effort. Here's what we know.

### Problem #1 — Screen littering

This aspect of the problem is specific to Windows1. The timer mechanism that we use under Windows (WM_TIMER) turns out to be surprisingly low priority. Such an incredibly low priority that even low priority paint events (WM_PAINT) trump them. Windows will simply not issue a timer message if you starve the system by pumping higher priority messages (and everything is higher priority) at it.

So, anything which retriggers itself, requiring constant computation, will do it. For example, this will do it:

x=0;Dynamic[x++]


Then start typing, and you'll see the screen litter. This seems like it should have been easy to catch in retrospect, but hindsight is 20/20, and for whatever reason, we didn't see this.

The timer thing has always been true under Windows, but in v10, we started pushing more things through the standard event handling system and through timers (as opposed to running them through tight loops which ignore system events or handle them circuitously) in an effort to make the entire system more responsive. This effort led to the regression, which we never properly characterized until recently.

### Problem #2 — Rendering some graphics leads to high CPU usage

This turns out to be a problem on all platforms. Some graphics (it's difficult to properly characterize which ones, but typically complex ones with significant usages of Inset) lead to high CPU usage when onscreen. This high CPU usage doesn't come from Dynamic evaluation as one might expect...just displaying the graphic leads the FE to erroneously invalidate its cache of information used to format the graphic onscreen (and by format, I mean things like determining the width and height of things, the proper fonts and options to use, etc.). So, the FE keeps running this computation over and over again.

On every platform, displaying such a graphic will dominate one core of your CPU. On Windows, the act of doing so will then trigger problem #1, making what was originally a minor problem much more noticeable. Also, I suspect that recent versions include visualization functions which are more likely to expose the problem than earlier versions did.

This problem has been around for a frightfully long period of time, and it's entirely possible that it has been reported in the past. But, as a result of problem #1, the symptoms are much more serious, which raised the priority of looking at it.

### Fixes

We're working on fixes to both problems. I do not expect either of these problems to be fixed in the forthcoming 11.0.1, as the fixes to these problems carry sufficient risk that it would necessitate a significant delay in the 11.0.1 release. But it should be ready in the next release (sorry, I can't comment on the release date for that yet).

And, incidentally, we turned our attention to this bug when we received numerous reports from users about it (6 distinct users reported it to our Support team as of this writing). That's what gets our attention. As I've said many times before, if you want to influence WRI's priorities, the way to do so is to find other folks who have similar concerns and make yourself heard through the Support team. It's a good system which helps us to understand how to prioritize limited resources.

### Workarounds

If you have a self-triggering Dynamic, that might be an indication of a bug in your code which you should fix. Otherwise, or if you're running into a graphic coming from a visualization function which seems to be causing the problem, then temporarily hiding the offending cell will clear the litter. You can do this by scrolling the cell off the screen, or by hiding it inside of a closed cell group.

1 Note that I'm not making a claim that there are absolutely no screen-littering bugs on Mac or X. But if there are, they have a different root cause than this problem.

• Are there reports that are considered serious without multiple folks reporting it? I found couple that are fundamental for events handling (43672, 125053) but it is highly unlikely you will get many reports. Mostly because pople don't go so deep or it is tough to reduce the problem (needs LinkSnooper and knowledge what to look for). I can spam here and there that those issues should be reported but it can result in skewed meaning of "important report". – Kuba Sep 15 '16 at 7:02
• I understand resources are limited so I don't blame FE team, I just want to confirm it is what I should do in case of serious (subjectively) problems. – Kuba Sep 15 '16 at 7:03
• Another less common cause of excess CPU usage leading to screen litter is the existence of certain kinds of selections. So, e.g., open up the Plot home page, open the Details and Options section, and select any bit of text that includes an inline cell (typesetting). It will peg a CPU core, even if the help window is de-focused. This has also been fixed for the next release. – John Fultz Oct 25 '16 at 18:03
• Just to say that I have just encountered this on MMA 11.0.1.0 in Win 10 64 bit & here the problem is related to GraphicsRow & GraphicsGrid: 4 simple ListPlots display fine as e.g. {p1,p2,p3,p4} but both GraphicsRow/Grid[{p1,p2,p3,p4}] tie up a CPU, & with a little more effort (p1->ListLogPlot with -ve value) can make the kernel un-quitable and the FE unkillable except from TaskManager. Any workarounds other than avoid GraphicsRow/Grid? – Julian Moore Oct 8 '18 at 17:10
• @JulianMoore I think the worst symptoms of this bug could be made to go away by evaluating CurrentValue[\$FrontEnd, DelimiterFlashTime] = 0, which effectively disables the flashing bracket matching indicator that happens as you type. – John Fultz Oct 14 '18 at 2:04