Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Logic for SalInstance::Yield() when bWait is true?
Logic for SalInstance::Yield() when bWait is true?
 
   NeoOffice Forum Index -> NeoOffice/C Development
View previous topic :: View next topic  
Author Message
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Wed Mar 24, 2004 12:52 am    Post subject: Logic for SalInstance::Yield() when bWait is true?

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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Wed Mar 24, 2004 8:12 am    Post subject:

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
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Wed Mar 24, 2004 9:32 pm    Post subject:

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

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
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Wed Mar 24, 2004 10:15 pm    Post subject:

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 Shocked. 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 Smile

Commit is as follows:

Code:

Checking in inc/saldata.hxx;
/cvs/vcl/aqua/inc/saldata.hxx,v  <--  saldata.hxx
new revision: 1.8; previous revision: 1.7
done
Checking in source/app/VCLApplication.mm;
/cvs/vcl/aqua/source/app/VCLApplication.mm,v  <--  VCLApplication.mm
new revision: 1.4; previous revision: 1.3
done
Checking in source/app/salinst.cxx;
/cvs/vcl/aqua/source/app/salinst.cxx,v  <--  salinst.cxx
new revision: 1.12; previous revision: 1.11
done


ed
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice/C Development All times are GMT - 7 Hours
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.