Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rice!sun-spots-request
From: jrs@cs.williams.edu
Newsgroups: comp.sys.sun
Subject: Suntools: Locking & Batching and Resize interaction
Keywords: Windows
Message-ID: <8904031855.AA08264@welsh.cs.williams.edu>
Date: 22 Apr 89 16:52:53 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 3 Apr 89 14:55:06 EDT
X-Sun-Spots-Digest: Volume 7, Issue 240, message 9 of 13

I recently changed a graph editor program I'm working on so that the
animation is done with locking and batching in a retained pixwin, which
makes everything much smoother.  When you start up the program, everything
works fine.  However, if a user does a resize, all subsequent locked &
batched draws come out in purple, the foreground color.  But it's even
weirder than that.  I didn't lock & batch the screen refresh, so after the
resize the colors are all fine.  When the user drags a vertex across the
screen (which is done with locking & batching), however, the affected
rectangle turns purple.  (By the affected rectangle I mean the smallest
rectangular region enclosing all the pixels that are changed in one
batched draw.)  It would actually be quite a neat effect if I could
control it: it looks like a purple piece of cellophane whose corner is
connected to the cursor is being dragged accross the screen (it doesn't
move back with the cursor, however-- once a pixel has become purple it
doesn't change back).

One person suggested that maybe the routines copying the block of pixels
to the screen when pw_batch_off is called for some reason think that the
screen is only one bit deep.  This sounds plausible to me.  Does anyone
know how to tell it to update in 8-bits (or however many I'm using) or
does anyone have any other explanations, fixes etc?  Feel free to contact
me directly.  Thanks.

Josh Smith					jrs@cs.williams.edu
		(413) 597-6716
SU box 1964
Williams College
Williamstown, MA  01267