Re: Process to refresh OpenGL panes
* Paul Tarvydas <201108291708.17332.paul.tarvydas@rogers.com> :
Wrote on Mon, 29 Aug 2011 17:08:17 -0400:
|
| Every time a user types a character, (regenerate) is called. This
| just sends a message to the updater process.
|
| The updater blocks on mp:mailbox-read until a message comes in. Then,
| it regenerates the most-recent PDF image and displays it. If, in the
| meantime, more regenerate messages pile up in the queue (i.e. the user
| types characters quickly), the updater simply goes into a loop to
| clear the queue (i.e. dumps the piled up messages) and then blocks
| again waiting for a mp:mailbox-read.
Does this work as expected? If the `regenerate' events were generated
for a different interface, it would seem that dropping them would be
wrong, (I imagine it would be tough for a user to generate them
though...)
[GUI amateur here. Recently I was trying to deal with duplicate events,
and a flood of events where the capi interfaces were only interested in
the last event.
In these cases it felt like I was working against the CAPI callback
model: I found myself wanting to maintain a queue of length 1 (one queue
for each event type) and have the `updater thread' poll these queues.
(This ends up being an adhoc bugridden reimplementation of serve-events,
a separate thread for each interface of interest.)
Anyway, I think the conflict with the CAPI callback model seems to be my
desire to make certain chains of dependent computations "lazy", as
opposed to the "eager" callback model. On that note, I was wondering if
there was some undocumented hook into the thread (lisp process) for each
interface. This could be exposed as a callback that gets called in the
gui loop for that process at some specified point.
Perhaps this might alleviate the situation where it is not profitable to have
another thread interrupt the gui thread with capi:execute-with-interface.]
---
Madhu