Thank you for taking a look. However, that's what the GLFW folks said. :) They said it likely wasn't a GLFW issue demonstrated by the fact that drawing done by pure OpenGL commands and not SkiaSharp/Skia do not demonstrate this issue. The explanation was also that GLFW does almost nothing besides forward things to the underlying OS libraries. I verified the GLFW boing example (
https://github.com/glfw/glfw/blob/master/examples/boing.c) still doesn't exhibit this issue. (Note: One must place `display(); glfwSwapBuffers(window);` at the end of `reshape`.)
At some point, there was a regression, somewhere in the stack, because now this issue shows up even in the most simple, single-threaded case. (I was never convinced my threading code was wrong anyway, as it's very hard to get wrong in F#.) I am unable to get back to where this never happens in the single-threaded case, which makes me believe it's possibly a graphics driver issue or an issue uncovered by a graphics driver change.
I just don't know what to do. If the issue was in my reproducing example, I figure someone would have pointed it out already, as it's very simple. And it isn't clear how to resolve it when every part of the stack declares it a problem of some other part of the stack. While Skia or SkiaSharp may not have a concept of resizing themselves, they have a concept of drawing, and it seems plausible to me that if it's drawing to the wrong thing
(surface/canvas) then this could happen. Is that possible?
Are there any suggestions on how to whittle this down to a specific part of the stack?