On GdkGC, colors, efficiency



Hello,

I have been wondering about the following problem for a long time, and
never got to a conclusion despite of several searches in the m.l.
archives and gtk+ application sources. If it is a FAQ, well, I have
missed it :-(

I have a large number of small "elements" to paint on a drawing area,
each of them with a possibly different color, although in practise there
will be a farily small number of different colors used. When I say
"elements" I think of entities which are much more fine-grained than,
say, GTK widgets. Think of the single words in an HTML document, each
word being a different element.

Because of the way colors are handled in gdk, I wonder which, among the
following alternatives, is the best.

a) using only one GdkGC and changing the color before painting any
element. Note that, if I understand GDK correctly, "changing" involves
both allocating a color and setting it in the GC. (I suspect at least
the last operation requires a call to the X server)

b) requesting one new GC for each element. This way I pay the price of
allocating and setting the color once for each element, every subsequent
draw operation just reuses the previous GC. In this case I have to store
the GC in a field of the element. How many GC structures are allocated
on the X server side? Does the X server (or GDK?) try to cache GCs?

c) a variant of a) where I try to do caching myself, i.e. whenever I ask
for a GC with a particular color, I search in an hash-table (which I
have to maintain myself) to see whether such GC has already been
allocated, and return that one.

More generally, it isn't clear to me the cost (both in time and space)
of GC-related operations, especially those that involve requests to the
X server.

Thank you all for any help you can give

-- luca







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]