Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!cornell!uw-beaver!info-mac From: info-mac@uw-beaver (info-mac) Newsgroups: fa.info-mac Subject: Cursor (mouse) and screen bitmap Message-ID: <1804@uw-beaver> Date: Thu, 27-Sep-84 19:52:16 EDT Article-I.D.: uw-beave.1804 Posted: Thu Sep 27 19:52:16 1984 Date-Received: Thu, 4-Oct-84 02:04:09 EDT Sender: daemon@uw-beave Organization: U of Washington Computer Science Lines: 27 From: Avadis.Tevanian@CMU-CS-SPICE I have run into an interesting "problem" with the Mac. Let's suppose you have a need for some type of graphic operation that is not supported by QuickDraw, and it won't suffice to replace the standard ROM routines with your own (perhaps you have different parameters). Or, just suppose that you are a hacker who wants to do his own graphics directly on the screen's bitmap. Anyway, the problem, as best I can figure, is that there are these 16 long words starting at address 0x85c (I think). These 16 long words contain the "data under cursor." I think this means that when the cursor is drawn on the screen, the bits it has overwritten are saved, and then restored when the cursor is removed. (Why don't the routines that send the screen bitmap out to the video display just merge in the cursor's bitmap when appropriate?) The problem: when you write into the bitmap at an address that is covered by the cursor, the new bits don't get put into the "data under cursor" long words. So, any graphics you do under the cursor disappear when the cursor is moved! A quick hack around this is to call HideCursor before the graphics operation, then ShowCursor when you are done. But, unless done carefully, you'll end up with a flickering cursor. Does anyone know if there is a "better" way to get around this problem? I guess the real question is, how does QuickDraw get around this problem? Avie PS: No flames about not using QuickDraw please.