From Electron Cloud
Revision as of 21:01, 25 September 2007 by Ecloud (Talk | contribs) (New page: Initial results with dragging a button widget around are not good. I measured the latency like this: <pre> (input-loop (lambda (e) (let ([timestamp (current-time)]) ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Initial results with dragging a button widget around are not good. I measured the latency like this:

(input-loop
    (lambda (e)
        (let ([timestamp (current-time)])
             (set! event-latencies (cons (- (time->nanoseconds timestamp) (* 1000000000 (-> e 'time))) event-latencies)))

which should get the number of nanoseconds between the time the tslib event occurred (in C code) to the time the event object was received in the event loop, and accumulate those latencies in a list. Then I print out the list every 100 events, and reset it. As I drag the button around, the latencies are all over, going from less than 1/10 second to 3 seconds.

Hypotheses:

  • The garbage piles up - every event is a new object and they have to be collected some time
  • It takes more time to draw the button at its new position, than the time before another event comes in. The events get backed up in the TCP socket.

But I see that the painting is "bursty" - the rate of new buttons being painted is not smooth.

Ideas:

  • Implement a ring buffer in dsinp.scm for all events; then they never need to be created, only banged into a vector of vectors or some such. The trouble is that it's hard to use one vector for every kind of event, and no objects are allowed.
  • Use a different ring buffer for each event type. When polling the "event queue" (which is now virtual - not just one queue) check to see which buffer has the oldest event, and that's the next one to process.
  • Allow TCP to be the buffer - just keep processing the events one at a time, but bang values into the existing object rather than creating a new one each time. The contract is that the recipient of an event must either process it completely right away, or make a copy if he wants to keep it around.
  • If painting is taking too long, try to skip some events in the case that we are just dragging an object.
  • Need to create dsinp-local.scm anyway - it will be directly linked to tslib and will not use a socket. But I'm thinking most of the latency is somewhere else, not in TCP.