Browse Prior Art Database

Accelerated Hardware Cursor Glyph Exchanger

IP.com Disclosure Number: IPCOM000112270D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 36K

Publishing Venue

IBM

Related People

Erb, DJ: AUTHOR [+2]

Abstract

This method accelerates the task of changing the glyph of the screen's hardware cursor by reducing the amount of data that must be sent to the adapter. In addition, this method reduces the amount of hesitation that can occur as the cursor crosses window boundaries, preventing the illusion of "sticky" window borders.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 87% of the total text.

Accelerated Hardware Cursor Glyph Exchanger

      This method accelerates the task of changing the glyph of the
screen's hardware cursor by reducing the amount of data that must be
sent to the adapter.  In addition, this method reduces the amount of
hesitation that can occur as the cursor crosses window boundaries,
preventing the illusion of "sticky" window borders.

      While typical hardware cursors provide a maximum glyph size of
64 pixels by 64 pixels, most applications use glyphs much smaller
than that (often just 16x16), and often use a different cursor for
each window.  This method saves away the current width and height of
the glyph that is currently installed on the hardware, and compares
those dimensions with the width and height of the new glyph that is
required for the current window.

      When the cursor glyph is changed, if the new glyph is at least
as large as the previous glyph, only the new glyph data is sent to
the adapter.  There is no need to zero out the unused pixels of the
hardware's 64x64 glyph space, as was ordinarily done.  If the new
glyph is smaller than the previous glyph, it is only necessary to
clear the pixels used by the previous cursor that are no longer used
by the new glyph.

      Thus, when an application uses many 16x16 glyphs, only 64 bytes
of data are sent to the adapter (at 2 bits per pixel) instead of the
full 1024 bytes needed for a 64x64 cursor.  That amounts to a
data-transfer reduction of 93%.

     ...