14 Mar
2005
14 Mar
'05
9:17 a.m.
Paul Davis wrote:
Here's what happens when resizing the workspace (adding/removing tracks or
beats, etc...) :
- gui_sequence_resized() is called by gtk
- gui_sequence_resized() calls sequence_resize()
- sequence_resize() allocate some new stuff, and waits for the jack thread to sync
- then gui_sequence_resized() calls gui_refresh()
- gui_refresh() calls gui_draw_tracks() which itself queries the sequence in
various manners : how many tracks do you have ? what beats are on/off ? etc...
The point is because gui_draw_tracks() calls such functions as
sequence_get_tracks_num() which rely on the sequence data to be up to date,
there's a need for the jack thread to sync. That is because it's the job of the
jack thread to update the actual sequence data, because it's the one which knows
when it can do that safely.
Do you mean that I should avoid letting the gui query the sequence directly
about tracks number, beats status, etc ? And replace that by an event/callback
paradigm ? The sequence would raise signals for the gui to update itself, in the
same manner as user actions raise signals ?
If that is the case I think I'd go with my g_timeout reading informations from a
fifo and then calling the appropriate "callback" gui functions. Or maybe
there's
a way to use a general g_source in a thread-safe manner.
--
og
don't wait in the GUI. what you need to do is to
hook a notification
mechanism from the RT thread into the main event loop of the
GUI. having the RT thread write a byte to a FIFO or raise/lower a
semaphore are the two best generally available ways of having it
notify the GUI that something has happened that it needs to know about.
many programs use this mechanism.
I need to investigate that. Do you know of some simple application (I think I'd
get lost into Ardour) demonstrating your point ?
Message queues
would still be used to let the jack thread update itself the
"real" sequence. This is where would reside some latency : waiting for the jack
thread to get in sync. But the gui would never lock.
forget the idea of "sync". your GUI has no way to update more than
about 60-80 times a second anyway (because of the monitor refresh
frequency. your goal is to make sure that the GUI reflects the state
of the model/backend ASAP after the model/backend changes.