events req servicing v2, with background computation, mod

[lttv.git] / ltt / branches / poly / doc / developer / lttvwindow_events_delivery.txt

diff --git a/ltt/branches/poly/doc/developer/lttvwindow_events_delivery.txt b/ltt/branches/poly/doc/developer/lttvwindow_events_delivery.txt
index a3586c0accb76e13e517142dfd777348e1ee7284..4e77884a96b74a09ad3dc5682808ce6f7b6b939d 100644 (file)
--- a/ltt/branches/poly/doc/developer/lttvwindow_events_delivery.txt
+++ b/ltt/branches/poly/doc/developer/lttvwindow_events_delivery.txt
@@ -198,6 +198,44 @@ the initial request. This is the expected result. For the background processings
 that call viewer's hooks, they will be removed.
 
 
+A New "Redraw" Button
+
+It will be used to redraw the viewers entirely. It is useful to restart the
+servicing after a "stop" action.
+
+A New "Continue" Button
+
+It will tell the viewers to send requests for damaged areas. It is useful to
+complete the servicing after a "stop" action.
+
+
+
+Tab change
+
+If a tab change occurs, we still want to do background processing.
+Events requests must be stocked in a list located in the same scope than the
+traceset context. Right now, this is tab scope. All functions called from the
+request servicing function must _not_ use the current_tab concept, as it may
+change. The idle function must the take a tab, and not the main window, as
+parameter.
+
+If a tab is removed, its associated idle events requests servicing function must
+also be removed.
+
+It now looks a lot more useful to give a Tab* to the viewer instead of a
+MainWindow*, as all the information needed by the viewer is located at the tab
+level. It will diminish the dependance upon the current tab concept.
+
+
+
+Idle function (lttvwindow_process_pending_requests)
+
+The idle function must return FALSE to be removed from the idle functions when
+no more events requests are pending. Otherwise, it returns TRUE. It will service
+requests until there is no more request left.
+
+
+
 
 Implementation
 
@@ -423,7 +461,10 @@ occur often. The solution to it would be to save one state per priority.
 
 Weaknesses
 
-- None (nearly?) :)
+- There is a possibility that we must use seek if more than one interruption
+  occurs, i.e. low priority interrupted by addition of high priority, and then
+  high priority interrupted. The seek will be necessary for the low priority.
+  It could be a good idea to keep one saved_state per priority ?
 
 
 Strengths