[comp.windows.x] setting a clip region in a shared GC

medmunds@spark.Verity.COM (Mike Edmunds x7645) (09/08/89)

According to the Xt manual, the function XtGetGC returns a "read-only,
sharable GC."  A number of widgets that I have been looking at,
however, use XtGetGC to get sharable GC's and then set the clip
regions in these GC's within their expose methods.  It seems
reasonable that a widget would want to use the clip mask to avoid
excess redrawing.  Which (if any) of the following statements is
correct?

1. A widget may alter the clip region in a shared GC.

This is what Douglas Young does in his dial widget (see "X Window
Systems Programming and Applications with Xt," p. 321), but seems
contrary to the Xt manual (and to Young's own statement on p. 186).

2. A widget may briefly alter a shared GC, but must undo any changes
it makes immediately after using them.

This is what the Athena scrollbar widget appears to do (in my
unpatched MIT X11R3 sources).

3. A widget may never alter a shared GC.

This is what the manual says, but would mean that any widget wanting
to take advantage of the expose method's region parameter would have
to use only private GC's.  The unfortunate implication would be that
an application using a large number of these widgets would create an
equally large number of GC's differing only in their clipping regions.

Any information on this would be greatly appreciated.

- Mike Edmunds
  Verity, Inc.			(standard disclaimers)

swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/09/89)

> Which (if any) of the following statements is
> correct?
>
> 1. A widget may alter the clip region in a shared GC.

not without additional constraints.

> 2. A widget may briefly alter a shared GC, but must undo any changes
> it makes immediately after using them.

This works just fine as long as you're single-threaded and is
an acceptable approach.  "Immediately after using them" should
be interpreted as "before returning from the procedure which
made the modification".  [If you've gotten things to work in
a multi-threaded environment, let us know! :-)]

> 3. A widget may never alter a shared GC.

Has the combinatorial problem that you point out, so the
"leave-it-as-you-found-it" rule is generally to be preferred.

swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/09/89)

> "Immediately after using them" should
> be interpreted as "before returning from the procedure which
> made the modification".

... and before calling any other procedure which might
execute in the context of a different widget.