Path: utzoo!dciem!nrcaer!sce!cognos!emoffatt From: emoffatt@cognos.UUCP (Eric Moffatt) Newsgroups: comp.arch Subject: Re: Hardware mice pointers Message-ID: <8519@cognos.UUCP> Date: 21 Jun 90 16:18:49 GMT References: <136288@sun.Eng.Sun.COM> <6537@vax1.acs.udel.EDU> <90Jun17.102245edt.2802@ois.db.toronto.edu> Reply-To: emoffatt@cognos.UUCP (Eric Moffatt) Organization: Cognos Inc., Ottawa, Canada Lines: 40 In article <90Jun17.102245edt.2802@ois.db.toronto.edu> jonah@db.toronto.edu (Jeff Lee) writes: > >The biggest advantage of a hardware cursor is *not* that it can be moved >quickly, but that (if it is a "sprite") it does not have to be unmapped >before doing graphical operations which might overlap it. > This is a good point. Any (even fairly) recent graphics system has enough horsepower to adequately track a cursor. For at least some applications (like graphics editors) the amount of time spent refreshing the tracking CURSOR is truly insignifigant compared to the overhead incurred by handling the shape dragging, rubber banding and dynamic information display. After all, the MAXIMUM number of updates is determined by the screen refresh rate (~60 Hz) and the acceptable level is usually far less (I get away with ~20/sec). Let's see, 20 tracks/sec = 50 msec/track which gives a fair bit of time to handle each track. Jeff's point is that not having a hardware cursor causes the whole graphics output pipe to be concerned with the cursor area in order not to corrupt the image, slowing down performance. This can be bad for high graphics volume applications like (M)ECAD. Even here, unless the tiling engine is extremely fast (ie. Silicon Graphics) the clipper should be able to handle the clipping of the output primitive against the cursor rect in its microcode. For my money ;-) a hardware cursor would be of extremely limited value. Give me a good BLTer (with a SET_WITH_TRANSPARENT_BACKGROUND op) and leave the rest to the software and microcode guys. The implementation should be at the lowest possible level, maybe somewhere between the atomic clipping/tiling operations and the graphic primitive handler. This would also allow possible future tracking 'fads' like multi-colour cursors to be implemented without getting burnt by hardware limitations. Of course if it's really not that expensive... -- Eric (Pixel Pusher) Moffatt - Cognos Incorporated: 3755 Riverside Drive Voice: (613)738-1440 (Research) FAX: (613)738-0002 P.O. Box 9707 uucp: uunet!mitel!sce!cognos!emoffatt Ottawa, Ontario, arpa/internet: emoffatt%cognos.uucp@uunet.uu.net CANADA K1G 3Z4