GNOME Bugzilla – Bug 87489
inconsistant interpolation for scaled bitmaps
Last modified: 2004-12-22 21:47:04 UTC
when you scale images in the theme, some are rendered with GDK_INTERP_NEAREST (when you scale in only one direction), some with GDK_INTERP_BILINEAR.I think what was intended was to use GDK_INTERP_NEAREST when you do not scale at all. simple patch: diff -u metacity_cvs/src/theme.c metacity/src/theme.c --- metacity_cvs/src/theme.c Sat Jun 22 05:23:00 2002 +++ metacity/src/theme.c Thu Jul 4 22:37:27 2002 @@ -2633,7 +2633,7 @@ switch (fill_type) { case META_IMAGE_FILL_SCALE: - if (gdk_pixbuf_get_width (pixbuf) == width || + if (gdk_pixbuf_get_width (pixbuf) == width && gdk_pixbuf_get_height (pixbuf) == height) { pixbuf = gdk_pixbuf_scale_simple (pixbuf,
I think the current behavior was intended, whether it's the ideal behavior I don't know. The point was to speed things up, since when scaling in a single direction you might often have an image that works fine with NEAREST (e.g. scaling the typical "edge" image that's a lot of vertical color bars, the bars just need extending).
Created attachment 9678 [details] rendering problem in metacity
when you composite your title bar from various images (e.g Crux) sometime you want to scale only vertically, sometime with apsect ratio 1:1. see attachement.
I see. One possible thing we could do is, when loading the theme, "analyze" images to see if they are just solid vertical bars or solid horizontal bars. If so, allow NEAREST to be used to scale them in the corresponding direction. Otherwise, always use BILINEAR. That may be overkill though, I don't remember how important this optimization was.
ok, why not: if an image is only bars, it should be only 1 pixel thick, and then we don't have to analyze. it's trivial to render with NEAREST when you scale in one direction of an image consisting of 1 line (or column). I can make a patch and a fixed Crux for this if you want. by the way: if a theme wants only stripes, is it faster to scale a bitmap with NEAREST or to use gtk primitives (lines, boxes, gradients) ?
That's a good point, that themes could just use the drawing primitives. I guess if it's causing problems to use NEAREST we should just drop that and go back to always using BILINEAR.
ok, sorry for having missed that "don't scale" was already special-cased. Soooo, after having actually read the source, I came up with the following patch. In most cases it stays out of the way, and if the theme exploits it, you can get some optimization. I updated Crux to trigger this, but was not able to notice any difference on my system. My bigger plan is to fix all available metacity themes. You can find modified versions of crux and gorilla here (not complete yet): http://sebdelestaing.free.fr/metacity/ and the patch: diff -ru metacity_cvs/src/theme.c metacity/src/theme.c --- metacity_cvs/src/theme.c Sat Jun 22 05:23:00 2002 +++ metacity/src/theme.c Sun Jul 7 20:23:49 2002 @@ -2633,8 +2633,8 @@ switch (fill_type) { case META_IMAGE_FILL_SCALE: - if (gdk_pixbuf_get_width (pixbuf) == width || - gdk_pixbuf_get_height (pixbuf) == height) + if ((gdk_pixbuf_get_width (pixbuf) == width && gdk_pixbuf_get_height (pixbuf) == 1) || + (gdk_pixbuf_get_height (pixbuf) == height && gdk_pixbuf_get_width (pixbuf) == 1)) { pixbuf = gdk_pixbuf_scale_simple (pixbuf, width, height,
I'm just putting in a patch to always use BILINEAR