performance of 2.4 under Linux

Glenn Krasner krasner at objectshare.com
Fri Jul 16 17:07:53 UTC 1999


At 01:42 PM 7/16/99 +0200, you wrote:
>> ...
>The systems previously cited probably have better display performance
>because they assume graphics "canvases" are external objects, which is much
>friendlier to X as they can be stored in server memory rather than in client
>memory when the display is remote.  I assume this is what Glenn was getting
>at when he said comparing VW with Squeak is like comparing apples to
>oranges.

Yes, we moved from the use of an internally-held bitmap whose affected
areas are copied to the platform's display, to the use of the display
"canvas" as an external object. We send it "display text", "draw line",
"fill rectangle" commands for those common operations, which involve
sending only a couple dozen bytes across the wire, rather than tens or
hundreds of thousands. (We also still support bitmap images, which still
take wire bandwidth to display but these are typically used much less
often.) In addition to avoiding network bottlenecks, there are other
advantages, for example being able to use the platform's fonts without
converting them into internal bitmaps.

This was a necessary change in our context, because we had demand for
color, "platform compliance", as well as being able to play in the
about-to-be-dominant [sic] world of ubiquitous low-cost X terminals. There
are disadvantages, especially in the amount of control over the graphics
world (no left-arrow in the fonts), but for our customers,this was a much
lower-priority.

Squeak today is in a much different context. Color works. Platform
compliance seems to be much less important. X terminals are gone as a
ubiquitous possiblity, although running X servers on local computers, as
used by Ian and Dick, is still somewhat common. Control over graphics is
important.

So my warning was that it's apples-and-oranges to compare graphics
performance of two very different architectures that came from very
different motivations.

By the way, while I agree that Ian's (a)-(e) apply in the Squeak context,
in the VW context, a couple them don't hold. In particular, the
re-architecting itself (d) was a signficant amount of work, but our system
is quite portable (b) with fairly low effort, none of which is
"unnecessary" in our context (e.g., where there is positive value in using
platform fonts) and the changes address much more than a network bandwith
symptom (e).

glenn





More information about the Squeak-dev mailing list