Another artefact that seems related (in that it happens on external displays not internal), opening Google Maps in the browser version, then using the mouse wheel to zoom in and out several times. The zoome judders and appears to be flicking bank and forth between one zoom level and another on occasion, rather than smoothly zooming out then in. Its like an old screen buffer from an earlier zoom level is being interspersed with the ones with the correct, progressive zoom level as the wheel is rolled, which matches the example of text scrolling I gave.

Here is either an example of this bug or it is an example of another bug...

https://1.wbl.me/bug.html

If you click on the word "Properties" you will get a bootstrap Modal that you can scroll up and down with using your mousewheel.

If you click on any of the buttons "htmlos.conf" you will get a similar modal but the scroll wheel doesn't work.

This behavior started last week sometime, Chrome autoupdates. It was difficult to repeat at first, but this page demonstrates the problem.

Weird scrolling issues.

OS X El Capitan
Version 10.11.6
Google Chrome is up to date
Version 70.0.3538.77 (Official Build) (64-bit)

#2 is a different issue. That relates to how the HTML is rendered, and whether it responds the HID control I guess.

This bug is not related to HTML at all, as the first example I give is in the command line shell crosh. It is certainly OS layer and related to surface composition on external displays in some way, on Chrome OS rather Mac.

I've continued experimenting - I'm noticing further artefacts that are not related to scrolling. When typing on an external display, the cursor intermittently jitters around, sometimes flicking back one character space then jumping forward again after a split second, and not drawing the character just typed until it jumps forward again. This gives the impression of latency or a missed key stroke which isn't the case, resulting in you retyping a character unnecessarily. Occasionally, the font seems unaligned or slightly different size, and then again corrects itself after a very short period. It seems to play into my guess that this is related to how drawing is composited and buffered in CrOS (although I only understand the mechanism very barely!). The effect seems more pronounced when composing a gmail, however, I am seeing it whilst typing this into crbug as well. Again, it is only on external displays, not the internal one. 

Also, occasionally the artefact is quite extreme, causing a large area of the display (>50%) to momentarily glitch and flick to another rectangle from somewhere else on the display, then back again.

Is there anything else I can do or supply to assist with this? Or diagnostics I can do? Its really distracting even just for typing, since this update.

I've upgraded to v71, and the bug is still present. And tbh, although I don't use the internal display of my chromebook very often (which is probably why I haven't noticed it until now) it seems the bug is present on the internal display as well.

In brief again - it appears that a previous screen buffer is being momentarily redisplayed, and then replaced with the correct screen buffer. End result is, whenever you change anything on the display (something gets painted, you type something, scroll the page, switch between tabs etc), at first it updates correctly, then intermittently and for a split second, it switches back to the previous paint/buffer, then back again to the correct one.

In practice, this is most distracting when you are typing - it looks like the character you just typed is painted, then it looks like you hit Delete as it disappears... for just long enough for you to try typing the character again, then the buffer flips back and you see you've ended up with 2 of the same character. Its very disruptive when touch typing as you are constantly, instinctively trying to correct something that isn't incorrect, and then genuinely having to correct your overcompensation!

Scratch that - I'm not able to reproduce this on the internal display, its just the external displaylink/dock connected displays that do it

Further info - I've noticed that what seems to trigger the buffer refreshing back to what it should be displaying (and 'uncorrupting' the screen again) is moving the mouse. If I scroll or update the screen in some way, and the corruption occurs leaving a chunk of the screen showing how it looked prior to scrolling, but I don't move the mouse at all, the corruption stays there indefinitely. As soon as I move the mouse, it corrects itself. Indeed, per my previous comment on typing, it seems that any input does this, so including typing more.