Are you sure this effect is caused by the 16.7 ms delay?
It's so fast and brief (single frame speed), that I believe it is.
Also if you didn't write the scrolling yourself, it may use a calculation which makes it not follow exactly on purpose. Something like: new_x = (old_x + touch_x) / 2; Or it may use momentum. Both would cause smoother movement, but add a delay.
That was my thought, too, but I think that's not the case.
Games that don't use a hardware cursor are even worse, since then the cursor itself is lagged.
Ah, true, I actually see this effect here in Windows 7.
Yea, that's the one. You can isolate the effect when storing mouse_x, mouse_y on the ALLEGRO_EVENT_MOUSE_AXES, then using them to draw something (which is shown beneath hardware cursor, usually delayed by ~1 frame). Moving the mouse slowly shows the drag most clearly.
Still, that's obviously fixable by simply redrawing the scrollbar at the same time as the mouse cursor and not at some later time.
You'd still have the vsync reaction problem, though. And/or you'd have to change the mouse cursor to include the component you're dragging.
After a few tests, a minimal lag still persists. Each solution I try (which only marginally reduced the drag) introduces potential new problems that only seems to worsen the overall situation. It seems that the minimal lag comes with no sync at all, which introduces tearing, while moving the update closer to the time of sync Destabilizes the 60fps cycle.