karstenwo at web.de
Sat Jan 22 02:42:56 UTC 2005
Am 22.01.2005 um 01:57 schrieb Tim Rowledge:
> Any vaguely recent version of VMMaker; deferDisplayUpdates is used in
> Interpreter>showDisplayBits:Left:Top:Right:Bottom: which is called by
Yes it's a Interpreter instVar and occasionally used in the image. I
wrapped BitBlt>>drawFrom:to:withFirstPoint: with a
deferUpdatesIn:while: back in a 3.5 image which gave a factor 2
speed-up. Problem with that approach are long, diagonal lines resulting
in big update rectangles.
> That calls a copyBits for the first point, which calls
> showDisplayBits, and then uses the primitiveDrawLoop which calls
> showDisplayBits for every time the affected area (measured rather
> tritely) exceeds 4000, not every time the copyBits is done.
Found it. Last changed in 2000. So i guess this was in when I started
looking at it in 2003.
> Note that _only_ if the target Form is theDisplay does any call to the
> platform specific code occur. Very often displaying os done to a buffer
Yeah, blitting to some form is _really_ fast. That's why I think we
still have to go a long way on OSX.
To make a long story short: the problem is not blitting from the
display form to the window. That's as fast as it could be. On OSX you
blit from SqueakBuffer to the window backBuffer calling
QDFlushPortBuffer() afterwards. It's that update call from the window
backBuffer to the foreBuffer that's causing problems. It's simply
called too often. The Squeak VM and the OS have improved in the last 18
month. My acid test for new VMs has improved from 40 to 11 Minutes.
If the following snippet takes more than 60 seconds on your machine
chances are you have the same problem (or your hardware is _very_ old).
"SqVM-381b2 676.314 TiBook 887MHz"
TimeProfileBrowser onBlock: [
| b |
b _ Pen new.
b place:(Display boundingBox bottomLeft).
b hilbert: 9 side: 2
That's more than 11 minutes. Under OS9 this runs in 25 seconds.
More information about the Squeak-dev