[racket] erasing a line?
On Fri, Jul 1, 2011 at 9:46 AM, John Riedl <riedl at cs.umn.edu> wrote:
> Robby:
>
> Thank you for the feedback.
>
> Overall the approach of drawing simultaneously onto the canvas dc and
> the backing bitmap, and then when I need to erase a part of the canvas
> just copying it over from the backing bitmap works. The speed
> improvement is lovely: at least a factor of 20 or so, and everything I
> need for my application.
>
> Two interesting problems that I ran into are:
>
> 1) The bitmap draw routines do not erase the rectangle they draw into.
> I don't know why. I ended up erasing the rectangle "by hand" with
> draw-rectangle with a transparent pen. (I tried 'solid and 'opaque
> styles. My backing bitmap and canvas are all default for things like
> monochrome? and alpha.)
I believe the default bitmap is one with no alpha component. If you
want one with an opaque background, then you have to initialize it
that way instead.
> 2) The draw-rectangle draws a little too big of a rectangle,
> presumably because of the outline it is drawing with the transparent
> pen. I had to make the draw-bitmap draw just a couple of extra pixels
> to make the erase work.
That doesn't sound right. Just to double check: coordinates are on the
boundaries between pixels, not on the pixels (and drawing in aligned
and smoothed and regular mode change some details here and there about
how lines are drawn, so maybe that's also confusing things).
> The invalidate approach I've seen in other graphics frameworks does
> this work for you: you issue an "invalidate" for a rectangle, and the
> paint routine is called with the dimensions of that rectangle, and a
> guarantee that the background is already erased. I guess the above is
> doing that "by hand", which is okay.
I think we don't have that particular API handy; just the lower-level
one that you're building on (that you could build that functionality
on top of; if you think it is worth doing, you could contribute a
planet package or a patch). We have a number of higher-level ones
around, but they would be too high-level for what you want, I think.
(FWIW, the editor hierarchy has that style of API built into it, but
you don't want an editor, I don't think.)
In general, the basic course we're steering is to provide just a
minimal API that comes from Cairo with only minor Racket-izations to
it and then to build what we need in Racket after that.
Glad to hear you got it working.
Robby