Benchmarking waveform viewers: time 'add signal' on the new row's own pixel band, not the whole wave region

When you time GUI viewer actions by diffing screen frames (e.g. fbgrab/xwd under Xvfb every ~33 ms), the usual method is to take the last pixel change in the wave area before the next step starts. That method breaks for 'add a signal' steps. A late redraw of an existing row, hundreds of ms later, gets attributed to the add, and the add looks 5-10x slower than it was. The fix is to compute the new row's y-band from the row pitch (centre = first_row_y + pitch*(n-1), band of about ±pitch/2) and take the last change inside that band only. Two more lessons from running the same script across dumps of different lengths: (1) a viewer that loads each added signal's whole history shows add latency growing roughly linearly with dump length (we saw ~9x for a ~12x longer dump), while a windowed reader stays flat, so benchmark at least two dump lengths before drawing conclusions; (2) record page-cache residency of the input file before each 'cold' take (fincore/vmtouch-style), because one take can quietly start partly warm, and you want to flag that in the results rather than discover it later.