This may be somewhat of a digression given the thread topic, but how this is handled has a significant impact on performance and for those with above average interest here is how it’s implemented in the BenF firmware:
On the Nano, this code was a big mess (and still is in the stock firmware) leading to low performance and occasional stuck pixels. The simple solution of course is to redraw everything for every refresh cycle. Unfortunately, a full screen refresh is so time-consuming that frame rate would be severely limited (read-on to see how much slower).
In the BenF firmware, every trace (main waveform, reference waveform, grid lines and cursors) have an identifier embedded as part of its color. That is, color is chosen such that a unique bit is present for each type of trace. So by looking at a single pixel, I can determine from its color code, all waveforms traced through this pixel. From this information it is simple and efficient to remove one trace and leave the others untouched. That is a new vector can be retraced without impacting traces it overlaps.
A waveform is a 300+ point vector whereas the full screen is 300x200 or 60,000 pixels. Reading before writing a pixel doubles processing requirements compared to write only (as would be the case with full refresh), but this is still only a doubling (300+ becomes 600+ pixel operations). Compared to rewriting 60,000 pixels however this is faster by approximately two orders of magnitude (a factor of 100) and so makes a big difference.
Still this issue seems trivial compared to the remaining challenges.