MacOSX Performance

Karsten Wolf karstenwo at web.de
Mon Jan 24 12:55:06 UTC 2005


Hi John,

Am 24.01.2005 um 08:38 schrieb John M McIntosh:

> b) We crash when we get a thread race condition on the runloopObserver 
> FlushAllBuffers() which attempts to flush the window, when we at the 
> same time are attempting to flush the window. That requires reading to 
> solve.
>
could you tell more. Sounds like relating to the problems I have.

> So what if I tried it at 200 times/second?
Lots of experimantation showed that 40 fps is really ok. Rethinking the 
whole issue in this thread takes me to the conclusion that 
QDFlushPortBuffer() _cannot_ be called more than ca. 200 times / sec. 
IIRC degradation begins at 80…100 fps (haven't tried that for a long 
time). This parameter is also _very_ machine specific. One of the early 
ideas I had was about some calibration tool to find the particular 
parameters for a specific machine. Still only an idea, since I don't 
know how to detect the correct parameters.

> a) sometimes a flush is left pending, not sure why since the dirty 
> region should be flush occasionally (perhaps not occasionally enough?)
>      Well I could do something about that if needed.
That flush is always pending if you use constructs as "Display 
restoreAfter:".

When I implemented the framerateUpdate (IIRC TN2030) I inserted a call 
to update somewhere in sqEvents.c. A small snippet that watched for 
pending updates to be flushed. The updater "posts" an update at 
now+minFPStimespan for the next update. Worked out fine except my vm 
hangs on ca. every 10th launch. I left it untouched for a year or so.

Recently I came up with another idea. Collecting the CopyBits() (as we 
all know, another interprocess call; perhaps with not so much 
limitations as QDFlushPortBuffer()) calls in a list of rectangles, 
merging to a given tilesize for adjacent blits. Looks very promising.


regards
karsten



More information about the Squeak-dev mailing list