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 129891 - better interpolation for images should be used
better interpolation for images should be used
Product: libgnomecanvas
Classification: Deprecated
Component: core
Other All
: High enhancement
: ---
Assigned To: libgnomecanvas maintainers
Federico Mena Quintero
: 317968 (view as bug list)
Depends on:
Blocks: 318065
Reported: 2003-12-23 11:49 UTC by Daniel Llano
Modified: 2005-10-06 22:26 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

Default to Hyper Interpolation (806 bytes, patch)
2003-12-23 21:35 UTC, Daniel Llano
none Details | Review

Description Daniel Llano 2003-12-23 11:49:13 UTC
gpdf seems to be using nearest neighbor interpolation and that gives very
bad output. Using a much better interpolator like GDK_INTERP_HYPER should
be at least optional if not default.
Comment 1 Martin Kretzschmar 2003-12-23 16:02:09 UTC
That's currently out of my control (the code that would have to be
changed is in libgnomeprintui). However, I'm considering to copy that
code into gpdf (for other reasons), so this change might become possible.
Comment 2 Daniel Llano 2003-12-23 17:33:14 UTC
Is gpdf using gnomeprint to show the document on screen?

That would be a bug in gnomeprint, wouldn't it?

I've seen the same problem in gnumeric print preview

This bug should be reassigned to gnome-print.
Comment 3 Daniel Llano 2003-12-23 18:03:07 UTC
I've reassigned to print preview component.
I've done a quick search for the image interpolator and I didn't find
it. Where's the code that should be changed to allow better interpolation?
Comment 4 Martin Kretzschmar 2003-12-23 19:38:56 UTC
Ooops.  I was wrong.  Not even gnome-print can do anything about the
interpolation method, it's hardwired in libgnomecanvas
(GnomeCanvasPixbuf) as far as I could  see.
Comment 5 Daniel Llano 2003-12-23 21:35:48 UTC
Created attachment 22670 [details] [review]
Default to Hyper Interpolation
Comment 7 Kjartan Maraas 2004-01-20 14:05:36 UTC
Please look at this patch.
Comment 8 Kjartan Maraas 2005-01-25 16:56:07 UTC
Is this very visible? I can try the patch and see if it makes a huge difference...
Comment 9 Daniel Llano 2005-01-26 09:59:19 UTC
Yes, It's a _HUGE_ difference using HYPER interpolation instead NEAREST
I can't work with NEAREST anymore in any app.
I think you should default to BILINEAR at least.
I'd like to have HYPER as default but maybe selection one or the other based on
CPU speed would be better idea.
Comment 10 Tim Janik 2005-05-16 14:22:59 UTC
the libart portion of this patch is unneccessary. libart only supports
ART_FILTER_NEAREST and is not developed any further.
using nearest for gdk is a waste though. this should be at least BILINEAR as
daniel said, but we might as well use HYPER since interpolating pixbufs is not
one of the performance critical portions of trhe canvas. so the gdk portion of
trhe patch sghould be applied:

@@ -958,7 +958,7 @@
 				   render_affine[5] - buf->rect.y0,
 	    gdk_pixbuf_unref (dest_pixbuf);
Comment 11 Kjartan Maraas 2005-05-19 14:06:44 UTC
Commited that hunk to both branches.
Comment 12 Philip Langdale 2005-10-05 17:09:19 UTC
The bug was that better interpolation should be used. The catch is that HYPER is
so buggy that BILINEAR is actually the better interpolation.
Comment 13 Philip Langdale 2005-10-05 17:10:32 UTC
*** Bug 317968 has been marked as a duplicate of this bug. ***
Comment 14 Philip Langdale 2005-10-05 17:11:13 UTC
See bug 317968 and bug 80923 for details.
Comment 15 Federico Mena Quintero 2005-10-06 22:22:54 UTC
Fixed on CVS in the gnome-2-12 and HEAD branches.

2005-10-06  Federico Mena Quintero  <>

	* libgnomecanvas/gnome-canvas-pixbuf.c
	(gnome_canvas_pixbuf_render): HYPER interpolation is a slow buggy piece of
	shit.  Use BILINEAR.  Fixes bug #129891.