Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watcgl.UUCP Path: utzoo!watmath!water!watcgl!mwherman From: mwherman@watcgl.UUCP (Michael W. Herman) Newsgroups: net.lang.st80,net.graphics Subject: bug in the blue book's implementation of *bitblt*? Message-ID: <2180@watcgl.UUCP> Date: Thu, 11-Jul-85 17:13:46 EDT Article-I.D.: watcgl.2180 Posted: Thu Jul 11 17:13:46 1985 Date-Received: Fri, 12-Jul-85 01:17:12 EDT Distribution: net Organization: Computer Graphics Laboratory, U of Waterloo, Ontario Lines: 113 Xref: watmath net.lang.st80:254 net.graphics:888 This article is directed to those of you who are using the *bitblt* operator described in the book "Smalltalk-80: The Language and its Implementation" (the "blue book") beit on a real Smalltalk machine or some other implementation that was faithfully derived from the Smalltalk code in the blue book. --------------------------------------------------------------------------- I have been using Simon Kenyon's *layers* software for bitmap graphics to implement the bitmap *rotate* operator described in blue book. I believe I may have found a bug in the Smalltalk code for *bitblt* given in the section entitled "Simulation of Bitblt" on pp. 355-361 of the blue book. First, let me say that I have modified Kenyon's C implementation so that it is almost statement-for-statement equivalent to the bluebook implementation. In particular, I have added the *clipRange* code which was completely missing. I have also corrected the code which calcualates *sourceDelta* in the *calculateOffsets* code. Secondly, the bug also shows up in another, independent implementation written about a year ago in a third language running on 8088 hardware. The bug that shows up in the version of *bitblt* I am now using is that it does not properly copy a 16 bit wide rectangle covering the left half of a 32x32 bit bitmap to a 16 bit wide rectangle covering the right half of the same bitmap. This is an operation that occurs as the 15th (last) *bitblt* operation in the *rotate* loop given on pp. 409-410 of the blue book and corresponds to the last operation in Figure 20.10 on p. 410. I believe the problem lies mostly in *checkOverlap* but the fix probably involves (possibly sweeping) changes to *calculateOffsets* and the *copyLoop* code. The following *layers* program performs the 3 bitblts given in Figure 20.10 of the blue book and illustrates the bug. The bug shows up when the last *bitblt* does not copy the left half of the bitmap to the right half. For those unfamiliar with the semantics of Kenyon's *bitblt*, they are bitblt( , , , , , ); ---------------------------------------------------------------------- #include #include extern struct Bitmap* display; main() { struct Bitmap* mask; struct Rectangle rect; struct Point dest_p; int quad; int width; width = 32; quad = width / 2; rect.origin.x = 0; rect.origin.y = 0; rect.corner.x = width; rect.corner.y = width; layers(); mask = balloc( rect ); /* set *mask* to all zeros */ fastclear( mask ); bitblt( mask, mask->rect, display, display->rect.origin, 0, S ); /* set top-left quadrant of *mask* to ones */ dest_p.x = -quad; dest_p.y = -quad; bitblt( 0, mask->rect, mask, dest_p, 0, ALL_ONES ); bitblt( mask, mask->rect, display, display->rect.origin, 0, S ); /* 13. make the *mask* half the size */ dest_p.x = -quad / 2; dest_p.y = -quad / 2; bitblt( mask, mask->rect, mask, dest_p, 0, S_AND_D ); bitblt( mask, mask->rect, display, display->rect.origin, 0, S ); /* 14. bottom half of *mask* <- top half of *mask* */ dest_p.x = 0; dest_p.y = quad; bitblt( mask, mask->rect, mask, dest_p, 0, S_OR_D ); bitblt( mask, mask->rect, display, display->rect.origin, 0, S ); /* 15. right half of *mask* <- left half of *mask*. this doesn't work */ dest_p.x = quad; dest_p.y = 0; bitblt( mask, mask->rect, mask, dest_p, 0, S_OR_D ); bitblt( mask, mask->rect, display, display->rect.origin, 0, S ); } ------------------------------------------------------------------------------- I very much like to hear from anyone who can support or deny that this bug exists in the blue book code. If anyone has a fix or an errata sheet for pp. 355-361 of blue book, that would be fantastic! Michael Herman Computer Graphics Laboratory Department of Computer Science University of Waterloo Waterloo, Ontario, Canada N2L 3G1 UUCP: {allegra,decvax,ihnp4,utcsri}!watmath!watcgl!mwherman CSNET: mwherman%watcgl@waterloo.CSNET ARPA: mwherman%watcgl%waterloo.CSNET@csnet-relay.ARPA