After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 105322 - gdk_draw_layout_line_with_colors performance
gdk_draw_layout_line_with_colors performance
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
unspecified
Other All
: Normal enhancement
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-02-05 17:46 UTC by Morten Welinder
Modified: 2005-11-09 02:34 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Description Morten Welinder 2003-02-05 17:46:35 UTC 
Gnumeric currently used pango layouts for drawing.  They all have a fore-
ground colour set.  Therefore, about 10% of gnumeric's time is spent
copying graphics contexts:

          fg_gc = gdk_pango_get_gc (drawable, context, (fg_set ||
foreground) ? &tmp : NULL,
                                    stipple, gc);

there has got to be some cheaper way of doing this, especially considering
that the foreground colour often matches the existing gc's colour.
Comment 1 Owen Taylor 2003-02-14 22:11:03 UTC 
All 3 backends included with GDK currently save the
foreground pixel value on the client side.

I'm sure a sufficiently determined person could come up
with a patch that:

 - Moved the caching of the foreground pixel value
   to the generic layer.
 - Added an accessor for it
 - Made gdk_pango_get_gc() return a ref'ed copy of
   the GC rather than a new GC if the passed
   in foreground color is NULL, or the pixel
   from gdk_rgb_find_color() matches the current
   foreground color.
Comment 2 Behdad Esfahbod 2005-11-09 02:34:40 UTC 
Closing as obsolete.  These kind of things are done in cairo these days, right?