GNOME Bugzilla – Bug 340965
Perspective tool preview corruption
Last modified: 2008-02-04 22:46:08 UTC
Please describe the problem: Looks like there is an issue with the altivec code for the image preview. Steps to reproduce: 1. open an image 2. pick the perspective tool 3. use it having preview: Image Actual results: you get lines of colors instead of the perspective of the image. Expected results: a preview of the transformed image Does this happen every time? yes Other information:
What altivec code?
Interesting question, I assumed that since I got this issue just on ppc it is related to cpu dependent code (same as the issue I experience with amd64 and warp) I'm rebuilding gimp w/out altivec optimizations to see if the issue is really related or the problem is somewhere else.
Created attachment 65049 [details] screenshot of the issue This is the problem I have just on preview. I hadn't the time to properly rebuild gimp-cvs w/out altivec
There is no altivec code involved here, and even if it was, you wouldn't have to rebuild gimp. Passing the --no-cpu-accel command-line option would be sufficient.
Same behaviour with --no-cpu-accel
Well, I can't replicate anything like this no matter what options I try for the perspective tool, so it seems likely to have something to do with ppc or some other idiosyncracy of your system. Could you clarify what distro you are using, and what version of Gtk+?
Portage 2.1_rc2 (default-linux/ppc/ppc32/2006.0/G4, gcc-4.1.0, glibc-2.4-r2, 2.6.17-rc3 ppc) ================================================================= System uname: 2.6.17-rc3 ppc 7447A, altivec supported Gentoo Base System version 1.12.0_pre19 dev-lang/python: 2.4.2-r1, 2.4.3, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r4, 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: 0.4.2 sys-apps/sandbox: 1.2.17, 1.2.18, 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="no" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=G4 -mtune=G4 -fno-strict-aliasing -pipe -maltivec -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" CXXFLAGS="-O2 -mcpu=G4 -mtune=G4 -fno-strict-aliasing -pipe -maltivec -mabi=altivec" MAKEOPTS="-j2" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS gtk+-2.8.17 in use I can reproduce the issue in other ppc systems but not on nonppc ones.
I have quite the same problem (layer rotation preview) with the same distribution and processor. If it can help.
It could be an endian issue.
Indeed. The tile_manager code used here received an optimization that is incorrect for big-endian machines. Should be fixed now. 2006-09-20 Sven Neumann <sven@gimp.org> * app/base/tile-manager.c (read_pixel_data_1) (write_pixel_data_1): fixed endian issues (bug #340965).
Same issue, obviously with every tool (perspective, rotate, shear, scale)... checked with current cvs again.
The problem is likely in GdkPixbuf then. We should probably reassign this to GTK+, but they would ask for a small test case. So the best thing to do here is to write a little test app that does similar GdkPixbuf operations.
This report needs a test case. It doesn't make sense to keep it on the 2.4 milestone if we assume that the problem is actually in GTK+.
I managed to make it work. First I upgraded to the latest stable version available with portage (Gentoo): glib-2.12.13 atk-1.18.0 cairo-1.4.10 pango-1.16.5 gtk+-2.10.14 gimp-2.2.17 The problem was still present. Then I recompiled glib and gtk+ with CFLAGS=-fsigned-char. Still nothing. Finally I recompiled the gimp with -fsigned-char and the issue seems solved now.
Closing as GENTOO then.
No, I don't think it's a Gentoo problem. I've just finished another test. I compiled gimp-2.2.17 in the usual configure/make way, with and without -fsigned-char. The result is the same: only with -fsigned-char it works fine. I also kept a log of the compile processes. The number of warnings reduced from 474 to 235 when I use -fsigned-char. Most of them are "argument x of 'func' differ in signedness". There are 46 warnings about broken aliasing rules only without -fsigned-char. If someone is willing to have a look at the logs, they are here (~60KB each): http://www.webalice.it/g_pochini/gimp.log.gz http://www.webalice.it/g_pochini/gimp_signed_char.log.gz I can contribute to fix this bug. Please tell me what code paths are involved, it will make my work much easier. $ uname -a Linux Jay 2.6.22.1 #3 SMP Sun Sep 16 15:39:49 CEST 2007 ppc 7455, altivec supported PowerMac3,6 GNU/Linux $ cc --version gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1)
The warnings are all fixed in 2.4 so your problem is most likely fixed as well.
I'm sorry, but it isn't. I've just tested 2.4.0-rc3: same disease and same cure. The following warnings disappear when I use -fsigned-char: warning: dereferencing type-punned pointer will break strict-aliasing rules curve.c:84 curve.c:131 curve.c:173 pxl-outline.c:64 pxl-outline.c:185 pxl-outline.c:189 spline.c:154 spline.c:221 I don't think the bug is in one of those files, though.
Definitely not as these files are in a plug-in which is not even involved. You are aware that you are asking for trouble if you are fiddling with compiler flags they way you are doing it, aren't you. That's why the bug was closed as GENTOO.
You can workaround the bug appending -fsigned-char to the default cflags or checking where there is a char instead of signed char in the code. In any case as today the svn source built with the default cflags is broken. PowerPC defaults char to unsigned char, Intel does the opposite, nothing related to Gentoo. Sorry for the delay
I don't see anything wrong in the code and it seems to work fine for other people on the PowerPC platform. So my assumption is that you are compiling your software stack inconsistently or are using experimental compiler features. Feel free to reopen the bug report if you found a particular change in the GIMP code that fixes your problem.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
forcing -fsigned-char hides the issue quite well, Gentoo will just force this flag for the time being.
I found the bug. This patch fixes the problem: --- gimp-2.4.4/app/display__orig/gimpdisplayshell-preview.c 2007-11-20 09:31:09.000000000 +0000 +++ gimp-2.4.4/app/display/gimpdisplayshell-preview.c 2008-02-04 22:55:09.000000000 +0000 @@ -828,7 +828,7 @@ gimp_display_shell_trace_tri_edge (gint { const gint dy = y2 - y1; gint dx; - gchar xdir; + gint xdir; gint errorterm; gint b; gint *dptr;
Obviously correct. Very well spotted. I have applied this to both branches: 2008-02-04 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-preview.c (gimp_display_shell_trace_tri_edge): use a gint for direction, not a gchar which might be unsigned. Patch from Giuliano Pochini; fixes bug #340965.