On Fri, Jul 1, 2011 at 10:55 AM, John Riedl <ri...@cs.umn.edu> wrote: >>> >>> 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. > > Ahhh! You put me onto the fix :). The problem is that I had read the > docs for make-object bitmap, which makes a bitmap with no alpha > channel. However, I was actually using make-bitmap, as recommended in > the docs. It turns out that make-bitmap reverses the default to > create an alpha channel -- but set to zero, whence the transparent > behavior. Once I changed the make-bitmap call to force no alpha > channel, I get the nice boring bitblt behavior I was expecting, so no > more need for drawing rectangles to erase the region first. (I think > your note above has the semantics of no alpha backwards: I believe no > alpha channel causes boring semantics, which an alpha channel makes > transparency possible.) > > In any case, this is a usability fail. The two ways of making bitmaps > should have the same defaults, even if their designers disagree on > which is preferred :). To whom do I mention that?
I think you're going to have to take it up with the 15 years or so of users that wrote code using make-object bitmap% before there was an alpha channel. :) In other words, this is an issue forced on us by backwards compatibility and we don't like it either. >>> 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). > > I'm not being that fancy. I just was erasing a rectangle of a given > size, and then bitblting in exactly that size of a bitmap from my > backing bitmap to exactly that location. The erase was erasing a > pixel more than the bitblt was bringing in, here and there. > Increasing the size of the bitblt by a pixel fixed the problem. I > think the easiest explanation is that the rectangle was drawing a > little too big ... Is it possible you were drawing the rectangle with a pen? Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
