Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!qmc-cs!ads
From: ads@cs.qmc.ac.uk (Adam Billyard)
Newsgroups: comp.windows.news
Subject: Re: problems with overlay canvases
Message-ID: <1192@sequent.cs.qmc.ac.uk>
Date: 23 Aug 89 08:39:37 GMT
References: <590@prlb2.UUCP>
Reply-To: ads@cs.qmc.ac.uk (Adam Billyard)
Organization: Computer Science Dept, Queen Mary College, University of London, UK.
Lines: 70
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <590@prlb2.UUCP> bernard@prlb2.UUCP (Bernard Yves) writes:
>
>there seem to be many problems with overlaycanvas in NeWS 1.1;
>here are some i have in my drawing editor:
...
>drawing with the marks, i tried to use an overlay canvas.  so i just
>changed the currentcanvas for that process to an overlay of the drawing
>window canvas. Since that, this process takes nearly all the cpu and blocks
>everything...
>/BlinkSelProcess
>               { %process code -- forked
>               setoverlay      %set the overlay canvas as current
>               { %now loop infinitely
>               current_selection  null ne
>                       {
>                       gsave  0.5 setgray
>                       /blink_mark current_selection send
>                       0.7 60 div sleep
>                       1 setgray
>                       /blink_mark current_selection send
>                       grestore
>                       } if
>               0.7 60 div sleep
>               } loop
>               } fork store

Your problem is that over canvases aggregate paths directed at
them, and so since you never do an "erasepage" the path gets
longer and longer, hence drawn "4 or 5 times". Added to this is
the fact that drawing bezier curves in overlays does seem pretty
slow. Overlays, though they sit uncomfortably in the NeWS
imaging model, do work. Try this..


/over currentcanvas createoverlay def
/path {0.2 0.2 0.3 0.3 rectpath} def

/feedbackproc
{
  over setcanvas
  clippath pathbbox points2rect 4 2 roll translate scale
  {
    path stroke
    0.5 60 div sleep
    erasepage
    0.25 60 div sleep
  } loop
} fork def

>- during polygon edition, when a vertex is dragged, animated feedback is
>made in the overlaycanvas by a process; this process stops when some
>events happen; for instance, if the user clicks in a scroll bar of the
>window, the animation process receives a `scroll' event and finishes,
>the main process reshapes the window canvas, recreates a new overlay
>canvas for it, redraws the screen, and restarts a new animation process
>in the new overlaycanvas; but now the animation does not work well: the
>segments of the polygon which are not changed by the dragging of the
>vertex are only seen when the mouse is dragged; if the mouse is not
>moved, they disappear... (as if they were displayed twice in XOR mode).

Same problem; use "erasepage"

        Adam.


-- 
--------------------------------------------------------------------------------
JANET:  ads@cs.qmc.ac.uk                 |    Famous lines of "Its a Knockout!":
ARPA:   ads%cs.qmc.ac.uk@nss.cs.ucl.ac.uk|  "Ah thank a weil playh, ma jockher."
BITNET: ads%uk.ac.qmc.cs@ukacrl.bitnet   |