Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.9/8.6.9) with ESMTP id SAA04725 for <executor@nacm.com>; Mon, 28 Nov 1994 18:58:35 -0800
Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id UAA09527 for nacm.com!executor; Mon, 28 Nov 1994 20:00:04 -0700
Received: by iclone (NX5.67d/NX3.0M)
id AA18729; Mon, 28 Nov 94 19:52:24 -0700
Date: Mon, 28 Nov 94 19:52:24 -0700
From: "Mathew J. Hostetter" <iclone!mat@sloth.swcp.com>
Message-Id: <9411290252.AA18729@iclone>
To: executor@nacm.com
Subject: Re: Linux Executor
Sender: owner-executor@nacm.com
Precedence: bulk
Jeff Tupper <mooncake@csri.toronto.edu writes:
>Where are the bitmaps/icons etc. stored on the Linux version of executor?
>Obviously, they would originate at the client, but are they cached on the
>server? (by watching if the mac memory holding the bitmap was changed) I
>implemented a copybits-like routine a few weeks back and was wondering what
>kind of trade-offs you guys made when doing yours.
All versions of executor maintain an internal bitmap corresponding to
the actual screen. We accrue a "dirty rect" as the program draws to
what it thinks is the screen via Executor's QuickDraw implementation.
We periodically update the _real_ screen (e.g., the X window) by
transferring the dirty rect across. So basically our graphics
interface to the host machine consists of nothing more than blitting
rectangles to the screen, which aids our portability. Under X, we use
shared memory extensions for speed, but we don't do anything fancy
like trying to cache Mac fonts on the X server side. Spending time
trying to do so would be a bad idea for a number of reasons I won't go
into.
"Refresh" mode is useful when the program directly manipulates the
frame buffer itself. In this mode, we periodically analyze the
internal screen memory to decide what has been changed, and transfer
