I've got a GTK app which shows an OpenGL image in a gtk_scrolled_window. I've also got an hscale control which is supposed to control the zoom of the image in the scrolled window.
Additionally, I'd like the center of the on-screen image to remain centered as I zoom----that is, keep the scroll values at the same relative percentage as the bounds change.
The current behavior is, so long as I only adjust the zoom one "value" at a time---say, by clicking elsewhere on the zoom bar, and not too fast---the system works as expected.
But if I adjust it too many times per second---say, by dragging it---the image redraw can't "keep up" and it disappears off to the upper-left. Adjusting the scroll bars themselves at all immediately jumps the image back to where it should be, though.
I tried posting some of my code here a month ago when I was first working on this issue, and no one replied. (I've since been doing other stuff.) So I'm not going to do that again. But the thread is here:
if you want to see it. I believe that code is pretty close to current.
My basic approach is to never allow drawing between one call to the scale change handler and two calls to the scroll bar change handler. Thus, the window won't try to draw the figure after the bounds have been changed but before the value has been changed.
I'd like to know if there's any way to synchronize the signals passed between widgets, so that the behavior is the same no matter how rapidly zoom-adjustments are made?
EDIT: An observation. If I drag the scroll bar (creating the problem), it appears to disable redraw on the window entirely until I click the scroll bar. Interesting. This could mean that the scrollbar's value-changed *isn't* signaled twice with every zoom change (one for each scrollbar).
Or it could mean I need to stick a mutex in there....does GTK use different threads for different signals?