bernard@prlb2.UUCP (Bernard Yves) (08/22/89)
there seem to be many problems with overlaycanvas in NeWS 1.1;
here are some i have in my drawing editor:
- the currently selected object is indicated by continuously making
blink small marks around it; this permanent highlighting is made by an
infinite loop in a separate NeWS process. In order to not damage the
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...
its code looks like this:
/setoverlay {win begin overlaycan end setcanvas} def
%win is the drawing window
%overlaycan is an instance variable of win and is set by
% win begin /overlaycan ClientCanvas createoverlay store end
/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
- when the current selected object is changed, this is indicated by
redrawing it; again in order to not damage the drawing area (there may
be overlapping objects upon it), i want to redraw it in the overlay
canvas. However, for mysterious reasons, the redrawing is made 4 or 5
times...which makes things quite slow if the object is complicated;
The code to set an object 'Obj' as the current selection looks like this:
KillBlinkSelProcess %kills the blinking selection process
/current_selection Obj store
currentcanvas %
setoverlay %set the overlay canvas as current
/display current_selection send
%strange : the redrawing is made 4 or 5 times in the
%overlaycanvas XORed with the underlying canvas...
setcanvas %restore previous canvas as current
MakeBlinkSelProcess %restart a new blinking process
- 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).
Anybody who knows the mysteries of overlay canvases in NeWS ?
Yves Bernard
Philips Research Lab, Brussels
bernard@prlb2.uucpads@cs.qmc.ac.uk (Adam Billyard) (08/23/89)
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 |