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 686514 - gdk_pixbuf_new_from_file_at_scale() fails to scale xpm images
gdk_pixbuf_new_from_file_at_scale() fails to scale xpm images
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
2.26.x
Other Linux
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
: 686910 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-10-20 08:53 UTC by Alexandre Rostovtsev
Modified: 2013-12-19 03:24 UTC
See Also:
GNOME target: ---
GNOME version: 3.5/3.6


Attachments
test program (906 bytes, text/plain)
2012-10-20 08:53 UTC, Alexandre Rostovtsev
  Details
test32x32.png (1.10 KB, image/png)
2012-10-20 08:54 UTC, Alexandre Rostovtsev
  Details
test32x32.xpm (4.50 KB, image/x-xpmi)
2012-10-20 08:54 UTC, Alexandre Rostovtsev
  Details
fix xpm scaling bug (567 bytes, patch)
2013-05-17 18:41 UTC, Xu Zhen
rejected Details | Review

Description Alexandre Rostovtsev 2012-10-20 08:53:30 UTC
Created attachment 226871 [details]
test program

(As reported downstream at https://bugs.gentoo.org/show_bug.cgi?id=438786)

With gdk-pixbuf-2.26.4, gdk_pixbuf_new_from_file_at_scale() and gdk_pixbuf_new_from_file_at_size() fail to scale xpm images. In other words, 
gdk_pixbuf_new_from_file_at_scale("foo.xpm", w, h, TRUE, NULL) results in a pixbuf whose width and height are the original width and height of foo.xpm, instead of the expected w x h.

Other image formats (e.g. png) are scaled correctly.

The attached program produces the following output:

test32x32.png has size 32 x 32
test32x32.png loaded at size 64 x 64, result is 64 x 64
test32x32.xpm has size 32 x 32
test32x32.xpm loaded at size 64 x 64, result is 32 x 32
Comment 1 Alexandre Rostovtsev 2012-10-20 08:54:19 UTC
Created attachment 226872 [details]
test32x32.png
Comment 2 Alexandre Rostovtsev 2012-10-20 08:54:53 UTC
Created attachment 226873 [details]
test32x32.xpm
Comment 3 Jeongsu Kim 2012-12-13 04:11:00 UTC
This problem is side effect of this commit.
http://git.gnome.org/browse/gdk-pixbuf/commit/gdk-pixbuf/gdk-pixbuf-loader.c?id=c62676a2843f391f32df2636d738e6333ae0318d

I reverted that commit and confirmed that resizing xpm is working.
Comment 4 Matthias Clasen 2013-03-02 15:28:05 UTC
*** Bug 686910 has been marked as a duplicate of this bug. ***
Comment 5 Xu Zhen 2013-05-17 18:41:51 UTC
Created attachment 244569 [details] [review]
fix xpm scaling bug

here is my patch to this bug.

with this patch, the size-prepared signal in gdk_pixbuf_loader_size_func() will not affect the pixbuf's width & height any more
Comment 6 Pacho Ramos 2013-05-26 19:07:40 UTC
Could the patch be reviewed to get it included (if possible) in the next release? Thanks a lot
Comment 7 Matthias Clasen 2013-05-30 23:40:30 UTC
Review of attachment 244569 [details] [review]:

The patch breaks the functionality of the size-prepared signal - it is supposed to modify the width, height that are passed in
Comment 8 Xu Zhen 2013-05-31 02:13:17 UTC
(In reply to comment #7)
> Review of attachment 244569 [details] [review]:
> 
> The patch breaks the functionality of the size-prepared signal - it is supposed
> to modify the width, height that are passed in

My patch won't break the functionality of the size-prepared signal.

Yes, the size-prepared signal is supposed to modify the width & height. But after the modification, the width & height is the size of the GdkPixbufLoader that passed into gdk_pixbuf_loader_prepare(), not the GdkPixbuf.

And whether to scale depends on the width and height in those two structures. So we cannot let the size-prepared signal modify the width and height variables, which contains the size of GdkPixbuf.
Comment 9 Emilio Pozuelo Monfort 2013-06-15 11:24:01 UTC
Matthias, any comments on the above?
Comment 10 Matthias Clasen 2013-06-15 14:42:25 UTC
haven't gotten back to this yet
Comment 11 Matthias Clasen 2013-12-19 03:24:26 UTC
thanks, the patch is right after all