Dave Mielke <[email protected]> wrote: > Things used to be synchronous. The code would scan forward to find a > non-blank > window, hit the end of the screen, play the alert tune for that, go back to > where it was, and then update the display. > > oiw things happen asynchronously. Waiting for each note of the alert tune to > complete opens up an opportunity for other events to run. What's happening is > that a screen update is running in the middle of the alert tune, before the > braille window coordinates have been restored to their original position. > > i'm wondering if it's worth suspending the screen update thread during an > alert > tune.
My main concern here is the additional and unnecessary write to the display, which it would be preferable to avoid. I haven't looked at how tasks are distributed among threads or what synchronization issues are in play, so I'll leave it to your judgment whether there's a safe and effective solution that wouldn't introduce further bugs. I suppose the other possibility would be to defer the alert tones until the coordinates have been restored, bug again, I haven't looked at it and I'd probably need to read a book on threaded programming first. _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
