Well as I wrote above, I had intended not to work on this until tomorrow, but it was bugging me too much so here I am again …
Thank you kindly, Michel, Merv, Christoph, and Jeff Tullin for your assistance …
I found that graphics rendering on Windows is indeed faster in earlier versions. I’ve used Xojo since 2001, and have almost every version since then installed already, but I had skipped 2016r1.1, so tried Xojo2015r2.41, and found that the canvas updating is in general faster, BUT the same problem remained. No updating during dragging.
I figured out what causes the problem. There are two canvases on the window. Dragging the box on the canvas in question fires its paint event, and then calls an update on the other canvas. It’s this call to update the other canvas that for some reason blocks invalidating the canvas in question. In pseudo-code:
// event called when box is dragged
' calculate some stuff
self.Invalidate
UpdateOtherCanvas ' <-- this causes the problem
When I comment out UpdateOtherCanvas, I get correct results.
I’ve run into this kind of thing before, on both platforms – that sometimes redrawing a control (for me usually listboxes) will simply not fire at a particular point in code. Calling Invalidate (or Refresh) sometimes has absolutely no effect, depending on where in the code it is called. Usually I solve the problem by calling a Timer which then calls Invalidate. Then it works. It is the “decoupling” of the call to invalidate or refresh that solves the problem.
My solution for now: on Windows, simply skip updating the other canvas during dragging. Update it only on MouseUp. It’s not as slick as Mac, which updates everything smoothly and looks perfect, but at least it doesn’t stall and stutter. It’s acceptable for Windows. So, I have essentially:
// event called when box is dragged
' calculate some stuff
self.Invalidate
#if TargetWin32 then
if WeAreDragging then return
#endif
UpdateOtherCanvas
Then the other canvas only gets updated on MouseDown and MouseUp. Not what I’d like, but acceptable.