home *** CD-ROM | disk | FTP | other *** search
- '\"
- '\" Copyright 1990 Regents of the University of California
- '\" Permission to use, copy, modify, and distribute this
- '\" documentation for any purpose and without fee is hereby
- '\" granted, provided that this notice appears in all copies.
- '\" The University of California makes no representations about
- '\" the suitability of this material for any purpose. It is
- '\" provided "as is" without express or implied warranty.
- '\"
- '\" $Header: /user6/ouster/wish/man/RCS/GetBitmap.man,v 1.7 92/05/21 11:32:21 ouster Exp $ SPRITE (Berkeley)
- '\"
- .\" The definitions below are for supplemental macros used in Sprite
- .\" manual entries.
- .\"
- .\" .HS name section [date [version]]
- .\" Replacement for .TH in other man pages. See below for valid
- .\" section names.
- .\"
- .\" .AP type name in/out [indent]
- .\" Start paragraph describing an argument to a library procedure.
- .\" type is type of argument (int, etc.), in/out is either "in", "out",
- .\" or "in/out" to describe whether procedure reads or modifies arg,
- .\" and indent is equivalent to second arg of .IP (shouldn't ever be
- .\" needed; use .AS below instead)
- .\"
- .\" .AS [type [name]]
- .\" Give maximum sizes of arguments for setting tab stops. Type and
- .\" name are examples of largest possible arguments that will be passed
- .\" to .AP later. If args are omitted, default tab stops are used.
- .\"
- .\" .BS
- .\" Start box enclosure. From here until next .BE, everything will be
- .\" enclosed in one large box.
- .\"
- .\" .BE
- .\" End of box enclosure.
- .\"
- .\" .VS
- .\" Begin vertical sidebar, for use in marking newly-changed parts
- .\" of man pages.
- .\"
- .\" .VE
- .\" End of vertical sidebar.
- .\"
- .\" .DS
- .\" Begin an indented unfilled display.
- .\"
- .\" .DE
- .\" End of indented unfilled display.
- .\"
- '\" # Heading for Sprite man pages
- .de HS
- .if '\\$2'cmds' .TH \\$1 1 \\$3 \\$4
- .if '\\$2'lib' .TH \\$1 3 \\$3 \\$4
- .if '\\$2'tcl' .TH \\$1 3 \\$3 \\$4
- .if '\\$2'tk' .TH \\$1 3 \\$3 \\$4
- .if t .wh -1.3i ^B
- .nr ^l \\n(.l
- .ad b
- ..
- '\" # Start an argument description
- .de AP
- .ie !"\\$4"" .TP \\$4
- .el \{\
- . ie !"\\$2"" .TP \\n()Cu
- . el .TP 15
- .\}
- .ie !"\\$3"" \{\
- .ta \\n()Au \\n()Bu
- \&\\$1 \\fI\\$2\\fP (\\$3)
- .\".b
- .\}
- .el \{\
- .br
- .ie !"\\$2"" \{\
- \&\\$1 \\fI\\$2\\fP
- .\}
- .el \{\
- \&\\fI\\$1\\fP
- .\}
- .\}
- ..
- '\" # define tabbing values for .AP
- .de AS
- .nr )A 10n
- .if !"\\$1"" .nr )A \\w'\\$1'u+3n
- .nr )B \\n()Au+15n
- .\"
- .if !"\\$2"" .nr )B \\w'\\$2'u+\\n()Au+3n
- .nr )C \\n()Bu+\\w'(in/out)'u+2n
- ..
- '\" # BS - start boxed text
- '\" # ^y = starting y location
- '\" # ^b = 1
- .de BS
- .br
- .mk ^y
- .nr ^b 1u
- .if n .nf
- .if n .ti 0
- .if n \l'\\n(.lu\(ul'
- .if n .fi
- ..
- '\" # BE - end boxed text (draw box now)
- .de BE
- .nf
- .ti 0
- .mk ^t
- .ie n \l'\\n(^lu\(ul'
- .el \{\
- .\" Draw four-sided box normally, but don't draw top of
- .\" box if the box started on an earlier page.
- .ie !\\n(^b-1 \{\
- \h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'
- .\}
- .el \}\
- \h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\l'|0u-1.5n\(ul'
- .\}
- .\}
- .fi
- .br
- .nr ^b 0
- ..
- '\" # VS - start vertical sidebar
- '\" # ^Y = starting y location
- '\" # ^v = 1 (for troff; for nroff this doesn't matter)
- .de VS
- .mk ^Y
- .ie n 'mc \s12\(br\s0
- .el .nr ^v 1u
- ..
- '\" # VE - end of vertical sidebar
- .de VE
- .ie n 'mc
- .el \{\
- .ev 2
- .nf
- .ti 0
- .mk ^t
- \h'|\\n(^lu+3n'\L'|\\n(^Yu-1v\(bv'\v'\\n(^tu+1v-\\n(^Yu'\h'-|\\n(^lu+3n'
- .sp -1
- .fi
- .ev
- .\}
- .nr ^v 0
- ..
- '\" # Special macro to handle page bottom: finish off current
- '\" # box/sidebar if in box/sidebar mode, then invoked standard
- '\" # page bottom macro.
- .de ^B
- .ev 2
- 'ti 0
- 'nf
- .mk ^t
- .if \\n(^b \{\
- .\" Draw three-sided box if this is the box's first page,
- .\" draw two sides but no top otherwise.
- .ie !\\n(^b-1 \h'-1.5n'\L'|\\n(^yu-1v'\l'\\n(^lu+3n\(ul'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c
- .el \h'-1.5n'\L'|\\n(^yu-1v'\h'\\n(^lu+3n'\L'\\n(^tu+1v-\\n(^yu'\h'|0u'\c
- .\}
- .if \\n(^v \{\
- .nr ^x \\n(^tu+1v-\\n(^Yu
- \kx\h'-\\nxu'\h'|\\n(^lu+3n'\ky\L'-\\n(^xu'\v'\\n(^xu'\h'|0u'\c
- .\}
- .bp
- 'fi
- .ev
- .if \\n(^b \{\
- .mk ^y
- .nr ^b 2
- .\}
- .if \\n(^v \{\
- .mk ^Y
- .\}
- ..
- '\" # DS - begin display
- .de DS
- .RS
- .nf
- .sp
- ..
- '\" # DE - end display
- .de DE
- .fi
- .RE
- .sp .5
- ..
- .HS Tk_GetBitmap tk
- .BS
- .SH NAME
- Tk_GetBitmap, Tk_DefineBitmap, Tk_NameOfBitmap, Tk_SizeOfBitmap, Tk_FreeBitmap, Tk_GetBitmapFromData \- maintain database of single-plane pixmaps
- .SH SYNOPSIS
- .nf
- \fB#include <tk.h>\fR
- .sp
- Pixmap
- \fBTk_GetBitmap(\fIinterp, tkwin, id\fB)\fR
- .sp
- .VS
- int
- \fBTk_DefineBitmap(\fIinterp, nameId, source, width, height\fR)\fR
- .VE
- .sp
- Tk_Uid
- \fBTk_NameOfBitmap(\fIbitmap\fB)\fR
- .sp
- .VS
- \fBTk_SizeOfBitmap(\fIbitmap, widthPtr, heightPtr\fB)\fR
- .VE
- .sp
- \fBTk_FreeBitmap(\fIbitmap\fB)\fR
- .sp
- Pixmap
- \fBTk_GetBitmapFromData(\fIinterp, tkwin, source, width, height\fB)\fR
- .SH ARGUMENTS
- .AS "unsigned long" *pixelPtr
- .AP Tcl_Interp *interp in
- Interpreter to use for error reporting.
- .AP Tk_Window tkwin in
- Token for window in which the bitmap will be used.
- .AP Tk_Uid id in
- Description of bitmap; see below for possible values.
- .AP Tk_Uid *nameId in
- Name for new bitmap to be defined.
- .AP char *source in
- Data for bitmap, in standard bitmap format.
- Must be stored in static memory whose value will never change.
- .AP "unsigned int" width in
- Width of bitmap.
- .AP "unsigned int" height in
- Height of bitmap.
- .AP "unsigned int" *widthPtr out
- Pointer to word to fill in with \fIbitmap\fR's width.
- .VS
- .AP "unsigned int" *heightPtr out
- Pointer to word to fill in with \fIbitmap\fR's height.
- .AP Pixmap bitmap in
- Identifier for a bitmap allocated by \fBTk_GetBitmap\fR.
- .VE
- .BE
-
- .SH DESCRIPTION
- .PP
- These procedures manage a collection of bitmaps (one-plane pixmaps)
- being used by an application. The procedures allow bitmaps to be
- re-used efficiently, thereby avoiding server overhead, and also
- allow bitmaps to be named with character strings.
- .PP
- \fBTk_GetBitmap\fR takes as argument a Tk_Uid describing a bitmap.
- It returns a Pixmap identifier for a bitmap corresponding to the
- description. It re-uses an existing bitmap, if possible, and
- creates a new one otherwise. At present, \fIid\fR must have
- .VS
- one of the following forms:
- .TP 20
- \fB@\fIfileName\fR
- \fIFileName\fR must be the name of a file containing a bitmap
- description in the standard X11 or X10 format.
- .TP 20
- \fIname\fR
- \fIName\fR must be the name of a bitmap defined previously with
- a call to \fBTk_DefineBitmap\fR. The following names are pre-defined
- by Tk:
- .RS
- .TP
- \fBgray50\fR
- 50% gray: a checkerboard pattern where every other bit is on.
- .TP
- \fBgray25\fR
- 25% gray: a pattern where 25% of the bits are on, consisting of all the
- bit positions that can be reached by a chess knight starting at (0,0).
- .RE
- .VE
- .LP
- Under normal conditions, \fBTk_GetBitmap\fR
- returns an identifier for the requested bitmap. If an error
- occurs in creating the bitmap, such as when \fIid\fR refers
- to a non-existent file, then \fBNone\fR is returned and an error
- message is left in \fIinterp->result\fR.
- .PP
- \fBTk_DefineBitmap\fR associates a name with
- .VS
- in-memory bitmap data so that the name can be used in later
- calls to \fBTk_GetBitmap\fR. The \fInameId\fR
- argument gives a name for the bitmap; it must not previously
- have been used in a call to \fBTk_DefineBitmap\fR.
- The arguments \fIsource\fR, \fIwidth\fR, and \fIheight\fR
- describe the bitmap.
- \fBTk_DefineBitmap\fR normally returns TCL_OK; if an error occurs
- (e.g. a bitmap named \fInameId\fR has already been defined) then
- TCL_ERROR is returned and an error message is left in
- \fIinterp->result\fR.
- Note: \fBTk_DefineBitmap\fR expects the memory pointed to by
- \fIsource\fR to be static: \fBTk_DefineBitmap\fR doesn't make
- a private copy of this memory, but uses the bytes pointed to
- by \fIsource\fR later in calls to \fBTk_GetBitmap\fR.
- .VE
- .PP
- Typically \fBTk_DefineBitmap\fR is used by \fB#include\fR-ing a
- bitmap file directly into a C program and then referencing
- the variables defined by the file.
- For example, suppose there exists a file \fBstip.bitmap\fR,
- which was created by the \fBbitmap\fR program and contains
- a stipple pattern.
- The following code uses \fBTk_DefineBitmap\fR to define a
- new bitmap named \fBfoo\fR:
- .nf
- .RS
- \fCPixmap bitmap;
- #include "stip.bitmap"
- Tk_DefineBitmap(interp, Tk_GetUid("foo"), stip_bits,
- stip_width, stip_height);
- \&...
- bitmap = Tk_GetBitmap(interp, tkwin, Tk_GetUid("foo"));\fR
- .RE
- .fi
- This code causes the bitmap file to be read
- at compile-time and incorporates the bitmap information into
- the program's executable image. The same bitmap file could be
- read at run-time using \fBTk_GetBitmap\fR:
- .nf
- .RS
- \fCPixmap bitmap;
- bitmap = Tk_GetBitmap(interp, tkwin, Tk_GetUid("@stip.bitmap"));\fR
- .RE
- .fi
- The second form is a bit more flexible (the file could be modified
- after the program has been compiled, or a different string could be
- provided to read a different file), but it is a little slower and
- requires the bitmap file to exist separately from the program.
- .PP
- \fBTk_GetBitmap\fR maintains a
- database of all the bitmaps that have been created.
- Whenever possible, it will return an existing bitmap rather
- than creating a new one.
- This approach can substantially reduce server overhead, so
- \fBTk_GetBitmap\fR should generally be used in preference to Xlib
- procedures like \fBXReadBitmapFile\fR or \fBXGetBitmapFromData\fR,
- which create a new bitmap on each call.
- .PP
- The bitmaps returned by \fBTk_GetBitmap\fR
- are shared, so callers should never modify them.
- If a bitmap must be modified dynamically, then it should be
- created by calling Xlib procedures such as \fBXReadBitmapFile\fR
- or \fBXCreatePixmap\fR directly.
- .PP
- The procedure \fBTk_NameOfBitmap\fR is roughly the inverse of
- \fBTk_GetBitmap\fR.
- Given an X Pixmap argument, it returns the \fIid\fR that was
- passed to \fBTk_GetBitmap\fR when the bitmap was created.
- .VS
- \fIBitmap\fR must have been the return value from a previous
- call to \fBTk_GetBitmap\fR.
- .VE
- .PP
- \fBTk_SizeOfBitmap\fR returns the dimensions of its \fIbitmap\fR
- .VS
- argument in the words pointed to by the \fIwidthPtr\fR and
- \fIheightPtr\fR arguments. As with \fBTk_NameOfBitmap\fR,
- \fIbitmap\fR must have been created by \fBTk_GetBitmap\fR.
- .VE
- .PP
- When a bitmap returned by \fBTk_GetBitmap\fR
- is no longer needed, \fBTk_FreeBitmap\fR should be called to release it.
- There should be exactly one call to \fBTk_FreeBitmap\fR for
- each call to \fBTk_GetBitmap\fR.
- When a bitmap is no longer in use anywhere (i.e. it has been freed as
- many times as it has been gotten) \fBTk_FreeBitmap\fR will release
- it to the X server and delete it from the database.
- .PP
- The procedure \fBTk_GetBitmapFromData\fR is a historical relic
- .VS
- from a time before \fBTk_DefineBitmap\fR existed; its use is
- discouraged nowadays and it may be deleted soon.
- \fBTk_GetBitmapFromData\fR serves as a combination of
- \fBTk_DefineBitmap\fR and \fBTk_GetBitmap\fR: given an in-memory
- description for a bitmap similar to what would be passed to
- \fBTk_DefineBitmap\fR (\fIsource, width, \fRand\fI height\fR),
- it returns a bitmap corresponding to that description that is
- suitable for use in window \fItkwin\fR.
- At present it does this by calling \fBTk_DefineBitmap\fR to
- define a name of the form ``\fB_tk\fInum\fR'' where \fInum\fR
- is an integer that starts at 1 and increments for each new
- combination of \fIsource\fR, \fIwidth\fR, and \fIheight\fR.
- Then it calls \fBTk_GetBitmap\fR.
- \fBTk_GetBitmapFromData\fR keeps a database of names and
- data, so that if the same \fIsource\fR, \fIwidth\fR, and \fIheight\fR
- are used again later, \fBTk_GetBitmapFromData\fR will re-use
- the original name.
- .VE
-
- .SH BUGS
- In determining whether an existing bitmap can be used to satisfy
- a new request, \fBTk_GetBitmap\fR
- considers only the immediate value of its \fIid\fR argument. For
- example, when a file name is passed to \fBTk_GetBitmap\fR,
- \fBTk_GetBitmap\fR will assume it is safe to re-use an existing
- bitmap created from the same file name: it will not check to
- see whether the file itself has changed, or whether the current
- directory has changed, thereby causing the name to refer to
- a different file.
-
- .SH KEYWORDS
- bitmap, pixmap
-