peter@ficc.ferranti.com (Peter da Silva) (06/15/90)
In article <WAYNE.90Jun14082016@dsndata.uucp> wayne@dsndata.uucp (Wayne Schlitt) writes: > when you move your mouse, > you need to erase the old cursor, draw a new one, check to see if it > has crossed a window boundary and such. Or you can just write new X and Y values into the hardware mouse pointer registers and forget about it. Why haven't hardware pointers caught on, then? It can't be the hardware cost or complexity: the necessary hardware has been part of cheap 8-bit computers for the past 10 years. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
phil@pepsi.amd.com (Phil Ngai) (06/16/90)
In article <W3048HB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: |Or you can just write new X and Y values into the hardware mouse pointer |registers and forget about it. Why haven't hardware pointers caught on, then? |It can't be the hardware cost or complexity: the necessary hardware has been |part of cheap 8-bit computers for the past 10 years. I believe that in the IBM-PC VGA world, it is very expensive to do in hardware. Some people have done it but I have heard quotes of around 10 to 15% more silicon, which is outrageous given the low margins in VGA devices. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil
peter@ficc.ferranti.com (Peter da Silva) (06/16/90)
In article <1990Jun15.213659.6206@bach.amd.com> phil@pepsi.amd.com (Phil Ngai) writes: > I believe that in the IBM-PC VGA world, it is very expensive to do in > hardware. Some people have done it but I have heard quotes of around > 10 to 15% more silicon, which is outrageous given the low margins in > VGA devices. Given the outrageous inefficiency of VGA type devices (I've heard quotes of on the order of 17 wait states to VGA memory for a typical 386), I'd have to agree that they're pretty marginal. More to the point, the speed up expected by going to a hardware cursor would be even more significant on that platform. For an X implementation that used it, that could be quite a selling point. Just make sure that it's not a repeat of the BellTech BLIT card. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
jgriffit@nyx.UUCP (Jonathan C. Griffitts) (06/16/90)
In article <W3048HB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Or you can just write new X and Y values into the hardware mouse pointer >registers and forget about it. Why haven't hardware pointers caught on, then? >It can't be the hardware cost or complexity: the necessary hardware has been >part of cheap 8-bit computers for the past 10 years. I was involved in designing the architecture of a RISC workstation a couple of years ago. We put in a hardware cursor manager (rather full-featured, including storage for both cursor shape and mask for up to 64x64 pixels, and "overlay" pallette options for the cursor). We were told by the people that were doing the X windows port that they didn't want a hardware mouse cursor and that they wouldn't use it if they had it. We designed it in anyway, as an optional feature that could be omitted in Manufacturing. This system did go into production (and is still being sold) but I do not know if the hardware cursor feature is being used. In case this issue comes up again, I'd like to know what the consensus is about this. Can X windows take advantage of a hardware mouse cursor? Jonathan Griffitts AnyWare Engineering, Boulder CO (303) 442-0556
david@eng.sun.com (Know Your Goldfish) (06/16/90)
In article <1308@nyx.UUCP> jgriffit@nyx.UUCP (Jonathan C. Griffitts) writes: >In case this issue comes up again, I'd like to know what the consensus is >about this. Can X windows [sic] take advantage of a hardware mouse cursor? Sure. Examples: DECstations running DECwindows. Sun workstations with GX frame buffers running OpenWindows. -- David DiGiacomo, Sun Microsystems, Mt. View, CA david@eng.sun.com
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (06/16/90)
In article <1308@nyx.UUCP> jgriffit@nyx.UUCP (Jonathan C. Griffitts) writes: >In article <W3048HB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>Or you can just write new X and Y values into the hardware mouse pointer >>registers and forget about it. Why haven't hardware pointers caught on, then? >>It can't be the hardware cost or complexity: the necessary hardware has been >>part of cheap 8-bit computers for the past 10 years. > For a hardware mouse pointer to work generally, doesn't the hardware have to have enough mouse pointer memory to allow storage of all the possible mouse pointers the user may want? Any given program might need three or four in addition to the system-wide ones. And this memory has to be writable by a program. So you might need say 32 mouse pointers. And some mechanism to change from one to another as it moves over various windows. How many screen systems have the necessary automatic mechanism to change mouse pointers as it moves? As I move the mouse around my present screen I count nine different mouse pointers. And I'm only running three programs. Doug McDonald
rcpieter@tuegate.tue.nl (Tiggr) (06/16/90)
In article <1990Jun16.142023.19048@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >As I move the mouse around my present screen I count nine different >mouse pointers. And I'm only running three programs. The Acorn Archimedes provides a hardware mouse pointer. The native OS provides 4 pointers between which it is easy to switch and which are easily definable. Normally, a user program may only reprogram one shape, the others being the default pointer and two for the running hourglass. The pointer can be only 32 pixels wide, and as high as the screen. Three colours plus transparant are availabl.e. If the pointer moves over an application's window the program receives an event and is allowed to change the pointer. On the BSD implementation on the Archimedes, the X Window System does not use this feature. Maybe because the 32pixel restriction is to restrictive, or maybe because it looks rather clumsy on hires (1152x900), where each pointer pixel is as wide as four normal screen pixels (this `feature' is not present in other non-hires screen modes). Tiggr -- Don't believe me, I'm a student.
peter@ficc.ferranti.com (Peter da Silva) (06/17/90)
In article <1990Jun16.142023.19048@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > For a hardware mouse pointer to work generally, doesn't the hardware have > to have enough mouse pointer memory to allow storage of all the possible > mouse pointers the user may want? No, just one. It's reasonable to reload the imagery for the relatively infrequent operation of crossing window borders (a few times a second, at most). This is a cheaper operation than blitting the cursor in, since we don't need to do any masking or shifting, just a straight copy. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
jonah@db.toronto.edu (Jeff Lee) (06/17/90)
tomw@orac.esd.sgi.com (Tom Weinstein) writes: >And any X implementor who claims that X can't use a hardware cursor is >wrong. The X I'm running right now uses it quite well. To properly support X11, a hardware cursor should be at least 16x16 pixels, allow for user-specified "hot-spots", and provide two (arbitrary) colors plus "transparent". Furthermore it should be relatively easy/cheap to (1) move the cursor and (2) change the cursor. Some of the "older" workstations don't support all of these options (e.g. two colors) so the "standard" X11 (MIT version) usually doesn't use them. As it stands, the X11R4 "software" cursor can be moved programatically at a rate of around 400 movements per second on an 8MB Sun-3/60 (approx 3MIP) workstation (which has a memory mapped frame buffer). 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. The biggest disadvantage is that there is typically only *one* (or some small finite number). Developers of multi-user collaborative software sometimes want users to see the mouse-cursor of other users as well as their own. If the hardware only supports a single cursor, you have to do the rest in software *anyways*. j.
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (06/18/90)
In article <1990Jun16.142023.19048@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >For a hardware mouse pointer to work generally, doesn't the hardware have >to have enough mouse pointer memory to allow storage of all the possible >mouse pointers the user may want? Any given program might need three or Mouse pointer storage could simply be some area of memory refered to by the hardware, which then displays the pointer without CPU intervention. If the pointers shape requires changing, simply re-map the address of the pointer bit map to the suitable design. The Amiga, and FM-Towns are two modern examples of sprite (read hardware cursor) technology done in that manner. The v7VGA board from Video Seven (for IBM PCs) supplies a single hardware cursor. I am not sure how it maps its sprite memory. >four in addition to the system-wide ones. And this memory has to be >writable by a program. So you might need say 32 mouse pointers. And some >mechanism to change from one to another as it moves over various windows. >How many screen systems have the necessary automatic mechanism to change >mouse pointers as it moves? That sounds like a brain dead way of implementing the cursor...the proper vantage point with which to view this is not to minimize memory bandwidth by having the sprites memory separate from the video, but that the CPU is not performing the masked copies and transfers required to implement the cursor in a non-hardware controlled cursor scheme. >As I move the mouse around my present screen I count nine different >mouse pointers. And I'm only running three programs. Thats not so much...the Amiga allows the hardware cursor to take up as many forms as can fit in 512k,1Mb,2Mb (pick your model) of video memory. Large amounts of semi-dedicated video memory, and hardware sprites have their advantages. (but hey, lets not get into a fight in alt. religion. computers ) :-) >Doug McDonald Lo-ha, -- Co-Op _____ "Bo doesn't know software" - George Brett Scum _/|__Q_\___ U of | ww--+----#\ "Catch the mystery catch the spit!" - Tom Saywer (Rush) Loo'91 ~~()~~~~~()~~ Glenn Patrick Steffler
emoffatt@cognos.UUCP (Eric Moffatt) (06/21/90)
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