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
|