Logic for SalInstance::Yield() when bWait is true?

[OPENSTEP]

Hey all...I've been looking over the logic in SalInstance::Yield() and how it's interacting with the timers. I'm wondering if the logic we've got in there is correct.

I would expect that bWait true would mean: wait until a user event is pending or until a timer expires. Right now the way GetAndRemoveEventFromQueue() is set up, it will block event dispatch until a timer expires even if there are events already waiting in the queue to be dispatched. This seems to be resulting in delay in responding to user input.

Any reflections on this logic? I'm thinking that if it's correct I'm going to toy around with changing the NSLocks over to NSConditionLocks where the condition of the lock indicates the presence (or lack) of items in the VCL event queue. GetAndRemoveEventFromQueue() would then use lockWithCondition:beforeDate: instead of explicitly sleeping the thread until the timer expiry to wake the thread when either an event is put on the queue or the timer expires, whichever is first. I'm going to bed now, but will mull it over and play with it tomorrow.

ed

[pluby]

Ed,

Not surprisingly, the logic in OOo that I reversed engineered for Dan that wen into this file was not totally correct.

Since Dan implemented the logic, I found a few bugs in that logic and have made a few updates since then. The latest logic that you should copy is in neojava/vcl/java/source/app/salinst.cxx (ignore the "flushAll" calls in the SalInstance::Yield() method).

The big point to remember is that all events generated by OOo must be dispatched before any events from the system event queue are dispatched. Intermixing these two event sources will usually cause the OOo code to eventually crash, particularly in presentations.

Patrick

[OPENSTEP]

Mein Gott! Dude, your code is commented!! And in English too

Looking at the javadoc comment for getNextCachedEvent(), the current interpretation of the wait parameter in the Neo Cocoa stuff is wrong...it's supposed to be a timeout that is allowed to expire if an event is posted, not a set timeout before any other events are processed. I'm going ahead and moving over to the condition locks now (but may need more beer first...)

Patrick, in case everyone hasn't told you so already, your pimphand is strong.

ed

[OPENSTEP]

OK, I just submitted modifications to the VCL event queue logic. The regular user queue has a simple lock, where the VCL queue now differs in that it has a condition lock. The condition lock conveys whether or not the queue is populated and the VCL thread blocks either until the timeout is reached or until an event is posted to the queue, whichever comes first. The end result is that the app is much more responsive to user input. For example, toolbar buttons now highlight nearly instantly when the mouse is in their region instead of being delayed based upon what the timer interval is.

The mouse coordinate location in sdraw is still not updating, however. I think this is a timer-based update mechanism. This may be an indication that what I did broke the timers . Other dispatches that I think are timer based (menu choice execution?) are occurring immediately, however. Of course, the drawing and app aren't stable enough for me to test out the dispatch requirements in presentation mode

Commit is as follows: