1XCreateGC(3)                    XLIB FUNCTIONS                    XCreateGC(3)
2
3
4

NAME

6       XCreateGC, XCopyGC, XChangeGC, XGetGCValues, XFreeGC, XGContextFromGC,
7       XGCValues - create or free graphics contexts and graphics context
8       structure
9

SYNTAX

11       GC XCreateGC(Display *display, Drawable d, unsigned long valuemask,
12              XGCValues *values);
13
14       int XCopyGC(Display *display, GC src, unsigned long valuemask, GC
15              dest);
16
17       int XChangeGC(Display *display, GC gc, unsigned long valuemask, XGCVal‐
18              ues *values);
19
20       Status XGetGCValues(Display *display, GC gc, unsigned long valuemask,
21              XGCValues *values_return);
22
23       int XFreeGC(Display *display, GC gc);
24
25       GContext XGContextFromGC(GC gc);
26

ARGUMENTS

28       d         Specifies the drawable.
29
30       dest      Specifies the destination GC.
31
32       display   Specifies the connection to the X server.
33
34       gc        Specifies the GC.
35
36       src       Specifies the components of the source GC.
37
38       valuemask Specifies which components in the GC are to be set, copied,
39                 changed, or returned .  This argument is the bitwise inclu‐
40                 sive OR of zero or more of the valid GC component mask bits.
41
42       values    Specifies any values as specified by the valuemask.
43
44       values_return
45                 Returns the GC values in the specified XGCValues structure.
46

DESCRIPTION

48       The XCreateGC function creates a graphics context and returns a GC.
49       The GC can be used with any destination drawable having the same root
50       and depth as the specified drawable.  Use with other drawables results
51       in a BadMatch error.
52
53       XCreateGC can generate BadAlloc, BadDrawable, BadFont, BadMatch, Bad‐
54       Pixmap, and BadValue errors.
55
56       The XCopyGC function copies the specified components from the source GC
57       to the destination GC.  The source and destination GCs must have the
58       same root and depth, or a BadMatch error results.  The valuemask speci‐
59       fies which component to copy, as for XCreateGC.
60
61       XCopyGC can generate BadAlloc, BadGC, and BadMatch errors.
62
63       The XChangeGC function changes the components specified by valuemask
64       for the specified GC.  The values argument contains the values to be
65       set.  The values and restrictions are the same as for XCreateGC.
66       Changing the clip-mask overrides any previous XSetClipRectangles
67       request on the context.  Changing the dash-offset or dash-list over‐
68       rides any previous XSetDashes request on the context.  The order in
69       which components are verified and altered is server dependent.  If an
70       error is generated, a subset of the components may have been altered.
71
72       XChangeGC can generate BadAlloc, BadFont, BadGC, BadMatch, BadPixmap,
73       and BadValue errors.
74
75       The XGetGCValues function returns the components specified by valuemask
76       for the specified GC.  If the valuemask contains a valid set of GC mask
77       bits (GCFunction, GCPlaneMask, GCForeground, GCBackground, GCLineWidth,
78       GCLineStyle, GCCapStyle, GCJoinStyle, GCFillStyle, GCFillRule, GCTile,
79       GCStipple, GCTileStipXOrigin, GCTileStipYOrigin, GCFont, GCSubwindow‐
80       Mode, GCGraphicsExposures, GCClipXOrigin, GCCLipYOrigin, GCDashOffset,
81       or GCArcMode) and no error occurs, XGetGCValues sets the requested com‐
82       ponents in values_return and returns a nonzero status.  Otherwise, it
83       returns a zero status.  Note that the clip-mask and dash-list (repre‐
84       sented by the GCClipMask and GCDashList bits, respectively, in the val‐
85       uemask) cannot be requested.  Also note that an invalid resource ID
86       (with one or more of the three most significant bits set to 1) will be
87       returned for GCFont, GCTile, and GCStipple if the component has never
88       been explicitly set by the client.
89
90       The XFreeGC function destroys the specified GC as well as all the asso‐
91       ciated storage.
92
93       XFreeGC can generate a BadGC error.
94

STRUCTURES

96       The XGCValues structure contains:
97
98       /* GC attribute value mask bits */
99
100       #define   GCFunction                  (1L<<0)
101       #define   GCPlaneMask                 (1L<<1)
102       #define   GCForeground                (1L<<2)
103       #define   GCBackground                (1L<<3)
104       #define   GCLineWidth                 (1L<<4)
105       #define   GCLineStyle                 (1L<<5)
106       #define   GCCapStyle                  (1L<<6)
107       #define   GCJoinStyle                 (1L<<7)
108       #define   GCFillStyle                 (1L<<8)
109       #define   GCFillRule                  (1L<<9)
110       #define   GCTile                      (1L<<10)
111       #define   GCStipple                   (1L<<11)
112       #define   GCTileStipXOrigin           (1L<<12)
113       #define   GCTileStipYOrigin           (1L<<13)
114       #define   GCFont                      (1L<<14)
115       #define   GCSubwindowMode             (1L<<15)
116       #define   GCGraphicsExposures         (1L<<16)
117       #define   GCClipXOrigin               (1L<<17)
118       #define   GCClipYOrigin               (1L<<18)
119       #define   GCClipMask                  (1L<<19)
120       #define   GCDashOffset                (1L<<20)
121       #define   GCDashList                  (1L<<21)
122       #define   GCArcMode                   (1L<<22)
123       /* Values */
124
125       typedef struct {
126            int function;            /* logical operation */
127            unsigned long plane_mask;/* plane mask */
128            unsigned long foreground;/* foreground pixel */
129            unsigned long background;/* background pixel */
130            int line_width;          /* line width (in pixels) */
131            int line_style;          /* LineSolid, LineOnOffDash, LineDoubleDash */
132            int cap_style;           /* CapNotLast, CapButt, CapRound, CapProjecting */
133            int join_style;          /* JoinMiter, JoinRound, JoinBevel */
134            int fill_style;          /* FillSolid, FillTiled, FillStippled FillOpaqueStippled*/
135            int fill_rule;           /* EvenOddRule, WindingRule */
136            int arc_mode;            /* ArcChord, ArcPieSlice */
137            Pixmap tile;             /* tile pixmap for tiling operations */
138            Pixmap stipple;          /* stipple 1 plane pixmap for stippling */
139            int ts_x_origin;         /* offset for tile or stipple operations */
140            int ts_y_origin;
141            Font font;               /* default text font for text operations */
142            int subwindow_mode;      /* ClipByChildren, IncludeInferiors */
143            Bool graphics_exposures; /* boolean, should exposures be generated */
144            int clip_x_origin;       /* origin for clipping */
145            int clip_y_origin;
146            Pixmap clip_mask;        /* bitmap clipping; other calls for rects */
147            int dash_offset;         /* patterned/dashed line information */
148            char dashes;
149       } XGCValues;
150
151       The function attributes of a GC are used when you update a section of a
152       drawable (the destination) with bits from somewhere else (the source).
153       The function in a GC defines how the new destination bits are to be
154       computed from the source bits and the old destination bits.  GXcopy is
155       typically the most useful because it will work on a color display, but
156       special applications may use other functions, particularly in concert
157       with particular planes of a color display.  The 16 GC functions,
158       defined in <X11/X.h>, are:
159
160       ───────────────────────────────────────────────
161       Function Name     Value   Operation
162       ───────────────────────────────────────────────
163
164
165
166       ()                                                                          ()
167
168
169
170       GXclear            0x0    0
171       GXand              0x1    src AND dst
172       GXandReverse       0x2    src AND NOT dst
173       GXcopy             0x3    src
174       GXandInverted      0x4    (NOT src) AND dst
175       GXnoop             0x5    dst
176       GXxor              0x6    src XOR dst
177       GXor               0x7    src OR dst
178       GXnor              0x8    (NOT src) AND (NOT
179                                 dst)
180       GXequiv            0x9    (NOT src) XOR dst
181       GXinvert           0xa    NOT dst
182       GXorReverse        0xb    src OR (NOT dst)
183       GXcopyInverted     0xc    NOT src
184       GXorInverted       0xd    (NOT src) OR dst
185       GXnand             0xe    (NOT src) OR (NOT
186                                 dst)
187       GXset              0xf    1
188       ───────────────────────────────────────────────
189
190       Many graphics operations depend on either pixel values or planes in a
191       GC.  The planes attribute is of type long, and it specifies which
192       planes of the destination are to be modified, one bit per plane.  A
193       monochrome display has only one plane and will be the least significant
194       bit of the word.  As planes are added to the display hardware, they
195       will occupy more significant bits in the plane mask.
196
197       In graphics operations, given a source and destination pixel, the
198       result is computed bitwise on corresponding bits of the pixels.  That
199       is, a Boolean operation is performed in each bit plane.  The plane_mask
200       restricts the operation to a subset of planes.  A macro constant
201       AllPlanes can be used to refer to all planes of the screen simultane‐
202       ously.  The result is computed by the following:
203
204       ((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
205
206       Range checking is not performed on the values for foreground, back‐
207       ground, or plane_mask.  They are simply truncated to the appropriate
208       number of bits.  The line-width is measured in pixels and either can be
209       greater than or equal to one (wide line) or can be the special value
210       zero (thin line).
211
212       Wide lines are drawn centered on the path described by the graphics
213       request.  Unless otherwise specified by the join-style or cap-style,
214       the bounding box of a wide line with endpoints [x1, y1], [x2, y2] and
215       width w is a rectangle with vertices at the following real coordinates:
216
217       [x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
218       [x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
219
220       Here sn is the sine of the angle of the line, and cs is the cosine of
221       the angle of the line.  A pixel is part of the line and so is drawn if
222       the center of the pixel is fully inside the bounding box (which is
223       viewed as having infinitely thin edges).  If the center of the pixel is
224       exactly on the bounding box, it is part of the line if and only if the
225       interior is immediately to its right (x increasing direction).  Pixels
226       with centers on a horizontal edge are a special case and are part of
227       the line if and only if the interior or the boundary is immediately
228       below (y increasing direction) and the interior or the boundary is
229       immediately to the right (x increasing direction).
230
231       Thin lines (zero line-width) are one-pixel-wide lines drawn using an
232       unspecified, device-dependent algorithm.  There are only two con‐
233       straints on this algorithm.
234
235       1.   If a line is drawn unclipped from [x1,y1] to [x2,y2] and if
236            another line is drawn unclipped from [x1+dx,y1+dy] to
237            [x2+dx,y2+dy], a point [x,y] is touched by drawing the first line
238            if and only if the point [x+dx,y+dy] is touched by drawing the
239            second line.
240
241       2.   The effective set of points comprising a line cannot be affected
242            by clipping.  That is, a point is touched in a clipped line if and
243            only if the point lies inside the clipping region and the point
244            would be touched by the line when drawn unclipped.
245
246       A wide line drawn from [x1,y1] to [x2,y2] always draws the same pixels
247       as a wide line drawn from [x2,y2] to [x1,y1], not counting cap-style
248       and join-style.  It is recommended that this property be true for thin
249       lines, but this is not required.  A line-width of zero may differ from
250       a line-width of one in which pixels are drawn.  This permits the use of
251       many manufacturers' line drawing hardware, which may run many times
252       faster than the more precisely specified wide lines.
253
254       In general, drawing a thin line will be faster than drawing a wide line
255       of width one.  However, because of their different drawing algorithms,
256       thin lines may not mix well aesthetically with wide lines.  If it is
257       desirable to obtain precise and uniform results across all displays, a
258       client should always use a line-width of one rather than a line-width
259       of zero.
260
261       The line-style defines which sections of a line are drawn:
262
263       LineSolid       The full path of the line is drawn.
264
265       LineDou‐        The full path of the line is drawn, but the
266       bleDash         even dashes are filled differently from the
267                       odd dashes (see fill-style) with CapButt
268                       style used where even and odd dashes meet.
269       LineOnOffDash   Only the even dashes are drawn, and cap-style
270                       applies to all internal ends of the individ‐
271                       ual dashes, except CapNotLast is treated as
272                       CapButt.
273
274       The cap-style defines how the endpoints of a path are drawn:
275
276       CapNotLast      This is equivalent to CapButt except that for
277                       a line-width of zero the final endpoint is
278                       not drawn.
279       CapButt         The line is square at the endpoint (perpen‐
280                       dicular to the slope of the line) with no
281                       projection beyond.
282       CapRound        The line has a circular arc with the diameter
283                       equal to the line-width, centered on the end‐
284                       point.  (This is equivalent to CapButt for
285                       line-width of zero).
286       CapProjecting   The line is square at the end, but the path
287                       continues beyond the endpoint for a distance
288                       equal to half the line-width.  (This is
289                       equivalent to CapButt for line-width of
290                       zero).
291
292       The join-style defines how corners are drawn for wide lines:
293
294       JoinMiter       The outer edges of two lines extend to meet
295                       at an angle.  However, if the angle is less
296                       than 11 degrees, then a JoinBevel join-style
297                       is used instead.
298       JoinRound       The corner is a circular arc with the diame‐
299                       ter equal to the line-width, centered on the
300                       joinpoint.
301       JoinBevel       The corner has CapButt endpoint styles with
302                       the triangular notch filled.
303
304       For a line with coincident endpoints (x1=x2, y1=y2), when the cap-style
305       is applied to both endpoints, the semantics depends on the line-width
306       and the cap-style:
307
308       CapNotLast      thin    The results are device dependent, but
309                               the desired effect is that nothing is
310                               drawn.
311       CapButt         thin    The results are device dependent, but
312                               the desired effect is that a single
313                               pixel is drawn.
314       CapRound        thin    The results are the same as for Cap‐
315                               Butt/thin.
316       CapProjecting   thin    The results are the same as for Cap‐
317                               Butt/thin.
318       CapButt         wide    Nothing is drawn.
319       CapRound        wide    The closed path is a circle, centered at
320                               the endpoint, and with the diameter
321                               equal to the line-width.
322       CapProjecting   wide    The closed path is a square, aligned
323                               with the coordinate axes, centered at
324                               the endpoint, and with the sides equal
325                               to the line-width.
326
327       For a line with coincident endpoints (x1=x2, y1=y2), when the join-
328       style is applied at one or both endpoints, the effect is as if the line
329       was removed from the overall path.  However, if the total path consists
330       of or is reduced to a single point joined with itself, the effect is
331       the same as when the cap-style is applied at both endpoints.
332
333       The tile/stipple represents an infinite two-dimensional plane, with the
334       tile/stipple replicated in all dimensions.  When that plane is superim‐
335       posed on the drawable for use in a graphics operation, the upper-left
336       corner of some instance of the tile/stipple is at the coordinates
337       within the drawable specified by the tile/stipple origin.  The
338       tile/stipple and clip origins are interpreted relative to the origin of
339       whatever destination drawable is specified in a graphics request.  The
340       tile pixmap must have the same root and depth as the GC, or a BadMatch
341       error results.  The stipple pixmap must have depth one and must have
342       the same root as the GC, or a BadMatch error results.  For stipple
343       operations where the fill-style is FillStippled but not FillOpaqueStip‐
344       pled, the stipple pattern is tiled in a single plane and acts as an
345       additional clip mask to be ANDed with the clip-mask.  Although some
346       sizes may be faster to use than others, any size pixmap can be used for
347       tiling or stippling.
348
349       The fill-style defines the contents of the source for line, text, and
350       fill requests.  For all text and fill requests (for example, XDrawText,
351       XDrawText16, XFillRectangle, XFillPolygon, and XFillArc); for line
352       requests with line-style LineSolid (for example, XDrawLine, XDrawSeg‐
353       ments, XDrawRectangle, XDrawArc); and for the even dashes for line
354       requests with line-style LineOnOffDash or LineDoubleDash, the following
355       apply:
356
357       FillSolid            Foreground
358       FillTiled            Tile
359       FillOpaqueStippled   A tile with the same width and height as
360                            stipple, but with background everywhere
361                            stipple has a zero and with foreground
362                            everywhere stipple has a one
363       FillStippled         Foreground masked by stipple
364
365       When drawing lines with line-style LineDoubleDash, the odd dashes are
366       controlled by the fill-style in the following manner:
367
368       FillSolid            Background
369       FillTiled            Same as for even dashes
370       FillOpaqueStippled   Same as for even dashes
371       FillStippled         Background masked by stipple
372
373       Storing a pixmap in a GC might or might not result in a copy being
374       made.  If the pixmap is later used as the destination for a graphics
375       request, the change might or might not be reflected in the GC.  If the
376       pixmap is used simultaneously in a graphics request both as a destina‐
377       tion and as a tile or stipple, the results are undefined.
378
379       For optimum performance, you should draw as much as possible with the
380       same GC (without changing its components).  The costs of changing GC
381       components relative to using different GCs depend on the display hard‐
382       ware and the server implementation.  It is quite likely that some
383       amount of GC information will be cached in display hardware and that
384       such hardware can only cache a small number of GCs.
385
386       The dashes value is actually a simplified form of the more general pat‐
387       terns that can be set with XSetDashes.  Specifying a value of N is
388       equivalent to specifying the two-element list [N, N] in XSetDashes.
389       The value must be nonzero, or a BadValue error results.
390
391       The clip-mask restricts writes to the destination drawable.  If the
392       clip-mask is set to a pixmap, it must have depth one and have the same
393       root as the GC, or a BadMatch error results.  If clip-mask is set to
394       None, the pixels are always drawn regardless of the clip origin.  The
395       clip-mask also can be set by calling the XSetClipRectangles or XSetRe‐
396       gion functions.  Only pixels where the clip-mask has a bit set to 1 are
397       drawn.  Pixels are not drawn outside the area covered by the clip-mask
398       or where the clip-mask has a bit set to 0.  The clip-mask affects all
399       graphics requests.  The clip-mask does not clip sources.  The clip-mask
400       origin is interpreted relative to the origin of whatever destination
401       drawable is specified in a graphics request.
402
403       You can set the subwindow-mode to ClipByChildren or IncludeInferiors.
404       For ClipByChildren, both source and destination windows are addition‐
405       ally clipped by all viewable InputOutput children.  For IncludeInferi‐
406       ors, neither source nor destination window is clipped by inferiors.
407       This will result in including subwindow contents in the source and
408       drawing through subwindow boundaries of the destination.  The use of
409       IncludeInferiors on a window of one depth with mapped inferiors of dif‐
410       fering depth is not illegal, but the semantics are undefined by the
411       core protocol.
412
413       The fill-rule defines what pixels are inside (drawn) for paths given in
414       XFillPolygon requests and can be set to EvenOddRule or WindingRule.
415       For EvenOddRule, a point is inside if an infinite ray with the point as
416       origin crosses the path an odd number of times.  For WindingRule, a
417       point is inside if an infinite ray with the point as origin crosses an
418       unequal number of clockwise and counterclockwise directed path seg‐
419       ments.  A clockwise directed path segment is one that crosses the ray
420       from left to right as observed from the point.  A counterclockwise seg‐
421       ment is one that crosses the ray from right to left as observed from
422       the point.  The case where a directed line segment is coincident with
423       the ray is uninteresting because you can simply choose a different ray
424       that is not coincident with a segment.
425
426       For both EvenOddRule and WindingRule, a point is infinitely small, and
427       the path is an infinitely thin line.  A pixel is inside if the center
428       point of the pixel is inside and the center point is not on the bound‐
429       ary.  If the center point is on the boundary, the pixel is inside if
430       and only if the polygon interior is immediately to its right (x
431       increasing direction).  Pixels with centers on a horizontal edge are a
432       special case and are inside if and only if the polygon interior is
433       immediately below (y increasing direction).
434
435       The arc-mode controls filling in the XFillArcs function and can be set
436       to ArcPieSlice or ArcChord.  For ArcPieSlice, the arcs are pie-slice
437       filled.  For ArcChord, the arcs are chord filled.
438
439       The graphics-exposure flag controls GraphicsExpose event generation for
440       XCopyArea and XCopyPlane requests (and any similar requests defined by
441       extensions).
442

DIAGNOSTICS

444       BadAlloc  The server failed to allocate the requested resource or
445                 server memory.
446
447       BadDrawable
448                 A value for a Drawable argument does not name a defined Win‐
449                 dow or Pixmap.
450
451       BadFont   A value for a Font or GContext argument does not name a
452                 defined Font.
453
454       BadGC     A value for a GContext argument does not name a defined GCon‐
455                 text.
456
457       BadMatch  An InputOnly window is used as a Drawable.
458
459       BadMatch  Some argument or pair of arguments has the correct type and
460                 range but fails to match in some other way required by the
461                 request.
462
463       BadPixmap A value for a Pixmap argument does not name a defined Pixmap.
464
465       BadValue  Some numeric value falls outside the range of values accepted
466                 by the request.  Unless a specific range is specified for an
467                 argument, the full range defined by the argument's type is
468                 accepted.  Any argument defined as a set of alternatives can
469                 generate this error.
470

SEE ALSO

472       AllPlanes(3), XCopyArea(3), XCreateRegion(3), XDrawArc(3), XDraw‐
473       Line(3), XDrawRectangle(3), XDrawText(3), XFillRectangle(3),
474       XQueryBestSize(3), XSetArcMode(3), XSetClipOrigin(3), XSetFillStyle(3),
475       XSetFont(3), XSetLineAttributes(3), XSetState(3), XSetTile(3)
476       Xlib - C Language X Interface
477
478
479
480                                                                            ()
Impressum