With code context shown, scrolling a window by dragging the scrollbar causes the scrollbar's tab to "jump around" and sometimes some "flashing" visual artifacts.

The "flashing" appears to occur only before the screen is resized for the first time, in which case the entire window is resized whenever the number of context lines changes during scrolling.

See attached animated screen capture.

Reproduced on latest versions of Win10 and macOS.

See also PR GH-14030, adding line numbers, which makes this more likely to occur for users.

I repeated Tal's experiment, on Windows, and added more.  I list below multiple issues related to code context and scrolling, and possible solutions.

1: two geometry modes.  After the text height is set on start up or by restore height, CC height is added to the fixed text height, making frame (and window height) vary.  After the window height is set by the user or zoom height, CC height is subtracted from the frame height, derived from the window height, making text height vary.

I don't remember noticing such switching between add and sub modes when CC height was fixed, but I presume it occurred. (I don't have pre-3.6.8 3.x to check.)  But it is now confusing and a nuisance.  I think we should prefer sub mode because add mode would undo correct zooming when zoomed, results in status line artifacts when row and column spaces temporarily left black, and is overall more obnoxious.  Perhaps we could do this by setting window height after setting text height.

2. text top.  With CC height varying, the top of text bobs up and down regardless of mode.  My initial opinion is that the visual effect is muted if the context foreground color is the same as normal text and the background similar.  Or maybe vice versa.  We might reconsider the current default, or add a doc recommendation.

We might experiment with border styles and their affect on the boundary between CC and text.

3. text bottom.  In sub mode, this stays put, but there is some white flashing that for me is only noticeable with a dark theme.  What happens seems to be this.  We start with n exposed lines of text and k lines of context. We change the exposed text, still n lines, by scrolling, whether with arrow key, mouse wheel, scrollbar arrow or trough clicks, or slider drag.  (No scroll arrows on my Macbook Air.) Suppose CC adjusts the context and the result is k' < k lines.  The text box increases by d = k-k' lines and the existing n lines are moved or copied  up.  In either case, the d lines at the bottom get a white background for a fraction of a second before being syntax colored.  

There are two oddities.  First, the padding between border and text line ends remains dark.  Second, after moving up and down a line where flashing happens, it sometimes stops after about 3 repetitions.  (Example editor.py, CC on, line 41 top line visible, move down and back up, repeat.)

Perhaps making sure that both toplevel and frame have the proper background will solve the issue.  I don't know the colorizer well enough to know whether it is relevant here.

4. scrollbar slider.  When the scrollbar jumps up or down with the text, 
the slider necessarily jumps up or down with it.  (I am ignoring slider size changes in sub mode, which will nearly always be minor in comparison.)  This is most obvious (and obnoxious) to me when dragging the slider, which I seldom do.

One way to prevent the bouncing is to fix the CC height, like it used to be.  Rather than revert, I would add a min height, so that min == max means fixed.  Another way to prevent the bouncing is to avoid mixing CC and scrolling, especially dragging.  Adding a CC hot key would enable quick looks at current context while mostly having it off.  With line numbers on, I think that this would be even more needed.

5. arrow keys (not related to CC).  With Notepad++, down arrow scrolls through editor.py (1722 lines), from beginning to end, at about 30 lines per second.  With IDLE on my machine, down arrow goes a few hundred lines at about 23 lines per second, with the cursor blinking as normal.  But then the cursor blinks off, and and scrolling stops for perhaps 2 seconds.  When the cursor comes back on, the file jumps about 50 lines.  This happens a few times, and the the cursor blinks off and stays off for at least several seconds.  It is like the key got tired and went to sleep.  If I then move the cursor some other key, arrow key works again, for a while.  Anyone else see anything like this?

The tests needed would mostly be suggestions added to an htest.

Regarding point #4, scrolling by dragging the scrollbar, note that the current PR for adding line numbers (GH-14030) does effectively the same when dragging on the line numbers to select lines.  Therefore, if/when that PR is merged, this will become more common.

> One way to prevent the bouncing is to fix the CC height, like it used to be.

+1 from me.  I find this behavior very distracting and unnatural.

I suggest we do consider reverting rather than adding another config value (minimum context lines), working towards our goal of simplicity and friendliness to novices and new users.

Whereas I found the fixed size to be much less usable.  The default of 3 lines was too few and often useless when context is needed whereas a realistic size of, say, 8, wasted too much space too much of the time.  I might prefer deleting the feature to reverting. 

It is probably a good thing to have 2 developers with different visual processing systems ;-).

With integral lines at the top of the text, scrolling one line down with a header line at the top means that the header line stays put while the background changes and the separator lines moves. A dedent line moves up as the context shrinks.  I *like* the CC size changes because the size indicates the indent depth.

Changing the general tab line from
  Max context lines:                              [ ]
to
  Code context lines:    min [ ]          max [ ]
strike me as an improvement even without adding min, and the somewhat obvious addition of min (it is currently fixed at 1) should not confuse users.  

The scrollbar slider bobble does not bother me much when scrolling with key or mouse wheel because I hardly see it.  My eyes are focused on the text.

Another possible solution is suppressing CC update at least while the mouse button is held down over the scrollbar.  Button down/up on the scrollbar instance sets text.pause_CC to True/False and CC update checks self.text.pauseCC.

> I *like* the CC size changes because the size indicates the indent depth.

My feeling is that you would be in a minority here.  IMO most new/novice users would find this surprising and confusing, since it is far from a customary UI experience.  Since our opinions obviously differ rather greatly on this, I suggest that we try to be objective and get some opinions from other users.

> The scrollbar slider bobble does not bother me much when scrolling with key or mouse wheel because I hardly see it.  My eyes are focused on the text.

On Windows, when scrolling with a mouse scroll wheel or a trackpad, I find that this makes scrolling rather inconsistent, since it will scroll more or less lines depending on the change in the number of context lines.

> Another possible solution is suppressing CC update at least while the mouse button is held down over the scrollbar.  Button down/up on the scrollbar instance sets text.pause_CC to True/False and CC update checks self.text.pauseCC.

I also see artifacts and scrollbar "jitter" when scrolling with a mouse wheel or trackpad, so IMO that wouldn't be a thorough enough solution.

'at least' means 'get something working, then consider expanding'.
The scrollwheel is tougher without built-in start/stop events equivalent to press/release.  We could, however, synthesize them.  But I want to start with mouse button, and it that works, consider keys next.