Graphical artifacts from selection squares in esc-demo snip

[bmitc]

Thanks so much for all your work on this project, providing it, and all of your blog posts! I was reading your blog post on custom snips and found your link to the esc-demo.rkt.

When running it with (show-demo-frame) and dragging the snip around, I get these artificial trails from the snip selection squares.

I know this is just a demo and not the point of this particular snip, but I didn't see it on your demo video. Also, I'm still coming up to speed on the pasteboard and snip functionality in Racket, and have seen this before in some of my experiments. Do you happen to know why this is happening?

I'm using Racket 7.9 CS on Windows 10.

[alex-hhh]

The artifacts are created by the "selection handles" which are drawn by the pasteboard. You can easily verify that by disabling them using (send pb set-selection-visible #f).

The artifacts happen because the draw method of the snip changes the dc to draw in "smoothed" mode and never restores the old state, but the pasteboard draws the handles expecting them to be unsmoothed, yet it never explicitly setting this state.

The patch below will resolve the issue, it updates the draw method of the snip to save the old smoothing state and restore it after the draw -- in general it is a good idea to do this for all drawing parameters used by a draw method (e.g. pens, brushes, etc), but it is sometimes difficult to follow through. I will also update the repository with this patch.

diff --git a/etc/esc-demo.rkt b/etc/esc-demo.rkt
index 7c82c73..d56ff8b 100644
--- a/etc/esc-demo.rkt
+++ b/etc/esc-demo.rkt
@@ -256,12 +256,14 @@
     ;; for the entire snip area, than we draw the controls by calling
     ;; `ai-draw`
     (define/override (draw dc x y . _)
+      (define old-smoothing (send dc get-smoothing))
       (send dc set-smoothing 'smoothed)
       (send dc set-brush (send the-brush-list find-or-create-brush background 'solid))
       (send dc set-pen (send the-pen-list find-or-create-pen item-color 0.5 'solid))
       (send dc draw-rectangle x y width height)
       ;; Draw all the controls
-      (ai-draw controls dc x y))
+      (ai-draw controls dc x y)
+      (send dc set-smoothing old-smoothing))
 
     ;; Handle mouse events sent to this snip.  We pass the events to the
     ;; controls using `ai-on-event` and if they are not handled we pass them
@@ -324,6 +326,7 @@
   (send f show #t)
   (define demo (new esc-control-demo-snip%))
   (send pb insert demo 10 10)
+  ;;(send pb set-selection-visible #f)
   (send canvas wheel-step #f))
 
 (printf "(1) Run (show-demo-frame) to show the demo snip in a separate frame~%")

[bmitc]

Thank you for this tip! I'll definitely need and use this moving forward.

Do you think that the pasteboard% should handle this itself? From your description and my understanding, it kind of seems like pasteboard% should take care of this, so I could potentially submit a patch for this to the GUI toolkit.

[alex-hhh]

I don't think this is a problem with the pasteboard% -- the drawing context is a shared resource and each function that uses it should save the old resources, modify them than restore them when finished. I already provided a fix for this in the patch above.

[bmitc]

Yes, I understand the fix. My thinking was wondering if the pasteboard% (in the GUI toolkit) should also not make any assumptions about the state of the drawing context, which I don't know exactly if it does or not, or if there's something else going on. My suspicions are there because I still see these and similar artifacts in many cases, usually when snips are overlapping, despite properly capturing and restoring the dc state, as you pointed out as and as the documentation mentions, which I missed until your help.

Thanks again for the help on capturing and restoring the dc state.