Re: [gtk-list] Re: How do I get r,g,b from gdk_gc_get_values?



Owen Taylor <owt1@cornell.edu> writes:

> It should work, but is a pretty expensive way of doing it.
> ColorContext's are heavyweight objects.

I suspected that might be a problem.

> (Eventually, you should be doing all color allocation through a CC,
> so you would typically allocate one at the start of your program and
> just use it throughout)

Makes sense.

> Either you created the GC yourself, in which case know what
> you set the foreground color is.

Nope.
 
> Or you got the GC out of widget->style, in which case there
> is a corresponding color entry (style->white_gc <=> style->white)
> which will have it's R,G,B filled in.

Ahh.  This is, in fact, the case.  I'm using w->style->black_gc.  I
didn't know about style->black...

The reason I need the RGB values from a GC is that I'm working on a
gtksketchpad which allows a changeable background, and "annotations"
(lines, rectangles, arcs, etc.) on top.  You can think of it as a very
lightweight (less featured) Tk Canvas approximation.  Key features are
that you can dump its contents as PostScript to a g_string, and that
(unlike a Canvas) it can handle *very* high frame rates with respect
to changing the background (at least if you don't have a bunch of
annotations).

The color issue arose because each "annotation" has a pointer to a
GdkGC, that helps determine it's appearance.  When the widget is asked
to render itself to PostScript, it needs to get the RGB values for the
gc foreground and background for each annotation.  It sounds like,
from what you've said, that I need to rethink this approach.

I'm not even sure how useful this widget might be.  Does it sound at
all like something of general interest?  Right now, I'm just playing
around because we need it here.

> (The reason that they aren't filled in for gdk_gc_get_values, is
> that the server just return sthe pixel for XGCGetValues, and it
> would be expensive to all XQueryColor to fill in the remainder, when
> it usually isn't needed. Or so I assume.)

That makes sense.

Thanks for the help, Owen.

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30



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