[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    Re: [9fans] =?iso-8859-1?Q?R=E9f._:_Re:_[9fans]_Re:_moving_things_in_a_window?=
From:       Theo Honohan <theoh () chiark ! greenend ! org ! uk>
Date:       2000-09-29 19:06:19
Message-ID: E13f5UC-0006Wd-00 () chiark ! greenend ! org ! uk
[Download RAW message or body]

In message <20000929145519.BF8D9199E8@mail>, "Russ Cox" writes:
> 	guess you can go a ways with xor :)
> 
> I think xor had little to do with it.  You could
> do it with the current draw about as easily.
> It seems to have come out of the trick of looking at
> the color of the pixels in your way to see if
> you are going to hit anything, rather than 
> keeping higher-level objects.
> 
> See http://research.microsoft.com/Users/luca/Papers/Crabs/Crabs.ps

That's fun.  It does mention that "Crab icons must be drawn in XOR
mode, to be able to restore the background when the crab moves away."
So the presence of XOR is crucial to the implementation -- if you
can't cheat by using XOR, then you have to do your best to efficiently
redisplay all the underlying objects.  Doug's suggestion would be one
way of doing that -- maybe that was his point.

It's also interesting (maybe) to think how you might efficiently
implement crabs "between" layers.

Hardware acceleration aside, I like the idea of avoiding a complete
redraw by keeping a "pre-blended" copy of each layer in backing store
in the server.
http://www.webcom.com/~haahr/montage/montage-usenix-s90.html

I suppose that could be a new refresh method -- or maybe it's the kind
of thing Refmesg is intended for.  Can you implement it with Refmesg
without breaking the "Laws" in the crabs paper?


[prev in list] [next in list] [prev in thread] [next in thread]