Browse Prior Art Database

Hardware Clipping Support for Raster Images

IP.com Disclosure Number: IPCOM000105991D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 6 page(s) / 202K

Publishing Venue

IBM

Related People

Klotzkin, DJ: AUTHOR [+2]

Abstract

In many graphics applications, it is desirable to clip a subset from a large image stored in system memory and display it to the screen. Clipping is used, for example, when a full screen image is displayed in a window smaller than the screen size. The part of that image that cannot be displayed is said to be clipped. Frequently, the subset and the source image are rectangular. Data is transferred from system memory to the screen through some hardware interface.

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

Hardware Clipping Support for Raster Images

      In many graphics applications, it is desirable to clip a subset
from a large image stored in system memory and display it to the
screen.  Clipping is used, for example, when a full screen image is
displayed in a window smaller than the screen size.  The part of that
image that cannot be displayed is said to be clipped.  Frequently,
the subset and the source image are rectangular.  Data is transferred
from system memory to the screen through some hardware interface.

      In some architectures, each item of data in system memory (a
"longword") corresponds to more than one pixel on the screen.  The
problem solved by this invention is how to specify and perform
clipped transfers when longwords transferred across the system bus
contain more than one pixel.  This involves deciding which pixels in
a particular longword to use, and which should be discarded as part
of the clipped portion of the image.

      Generally there is some interface between system memory and
video memory.  In a hardware oriented system, the interface will have
the capability to do rectangular block transfers.  That is, the
software will specify the starting point and the X and Y dimensions;
then pixel data will be supplied on the system bus, and the interface
will be responsible for writing the data to the correct addresses.
The approach outlined here is in addition to the hardware which keeps
track of the position on the screen and handles pixel addressing (the
"hardware blitter").

      Block transfers of video images are typically rectangles.  For
example, the user could specify that the next twenty pixels sent to
the interface are to be written as a five by four rectangle.

      The system bus is of fixed width, and can address only at
multiples of that width.  For the purposes of this disclosure and the
examples which follow, assume it is 32 bits wide, and can address
only at longword boundaries.  In some architectures, images are
sometimes stored in other formats, such as 8 bits per pixel (4 pixels
per longword).  This system memory can only send longwords; there
must be some means of specifying which pixels in the longwords are to
be used.

      As an example, suppose there is an 8 by 2 byte pixel memory map
in system memory.  It is desired to display a 4 by 2 subset of this
map on the screen, and it is stored in 1 byte per pixel format.  The
system memory transfers 4 bytes at a time, and the data is organized
in system memory as shown in Fig. 1.

       The 8 by 2 block is the entire image; the box indicates the
portion of the image that is to be displayed.  Each single number
represents a byte, and each group of four is an addressable entity, a
longword.

      Since all 16 pixels will be sent to the interface regardless,
there must be a means of selecting which pixels are to be drawn.

      The problem has another complication, which will be discussed
later;...