Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 04:13:19AM +0100, Marc A. Lehmann wrote:
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig [EMAIL PROTECTED] wrote:
other parts, and I already had enough with C guts) and is small, it
just fits in place with the old code instead of more deep changes.
True. (These break strict aliasing rules warnings however are harmless
according to Yosh.)
Just a sidenote, unless caused by a bug in the compiler, these warnings
are never harmless. They might not cause problems with current gcc,
but there is no guarentee that the code will do as expected with other
compilers or future versions of gcc, unless one uses -fno-strict-aliasing,
which can be a major performance problem in some cases.
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh wrote:
On Tue, Jan 20, 2004 at 04:13:19AM +0100, Marc A. Lehmann wrote:
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig [EMAIL PROTECTED] wrote:
other parts, and I already had enough with C guts) and is small, it
just fits in place with the old code instead of more deep changes.
True. (These break strict aliasing rules warnings however are harmless
according to Yosh.)
Just a sidenote, unless caused by a bug in the compiler, these warnings
are never harmless. They might not cause problems with current gcc,
but there is no guarentee that the code will do as expected with other
compilers or future versions of gcc, unless one uses -fno-strict-aliasing,
which can be a major performance problem in some cases.
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
does this count the things that you cannot do? it would be very silly
to tie a process up with this sort of thing. this list is infinite.
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
does gcc do this? count up things that it is not allowed to do? will
the compiler need to be rewritten?
carol
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice. Unfortunately I could not check GSR's patch because of compiling issues. Regards, JS -- On Monday 19 January 2004 23:22, Simon Budig wrote: (...) Unfortunately these two patches basically exclude each other and it will come to no surprise to you, that I'd prefer to see my own patch in 2.0. However, because it is so intrusive I won't commit it until somebody read my patch and gives me the OK to do it. Bye, Simon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh [EMAIL PROTECTED] wrote:
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
Well, troubling to me would be the fact that a int is not the same as
a void *, so this very example is a bit strange and could likely cause
problems on 64-bit (or else) architectures, but that is, of course, not
the main point.
I don't know the real case this is based on, but I'd wonder what this code
is supposed to do then. Please note that the warning will not happen when
you cast to a void *, since the pointers might alias then.
Legally, the compiler could cache the contents of i in a register before
and after the call, because foo is not allowed to change it's value. (And
I might guess that foo will not do that, but it's equally hard to see this
as a compiler as it is for a human, so the warning is IMnsO justified).
It's unlikely that this will happen with gcc = 3.5, which is, IMHO,
a viable platform to tie oneself to, but there are no guarentees that
this won't happen in more complicated cases, with other (less or more
intelligent) compilers or with future gcc versions.
It's hard to judge from his example, but right now it's difficult for
me to imagine a valid use for the above that couldn't easily be written
correctly.
To repeat it: I am quite certain that the above example will simply work
for quite some time in the future, because of some gcc assumptions about
pointers that are difficult to change but make no good otimized code.
Perl does similar pointer castings and has opted the safe way by simply
using -fno-strict-aliasing to compile itself at all times, after being
bitten once.
That might be easier then going through all the code and fixing it, and
will of course silence the warning. Right now, it doesn't make much of a
difference in generated code with gcc, as it is not very good at taking
advantage of (no-) aliasing yet, but this is a hot area in gcc, since
exploiting aliasing rules allow a great deal of optimizations in typical
numerical code.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Dithering
That's because the screen display code doesn't smooth the image when it scales it, for speed reasons. Dedicated viewing programs can afford to do a better job showing the image because they won't be re-drawing it quite so often (imaging panning around the image while editing it - you'd like that to be fast, right?) Austin -Original Message- From: [EMAIL PROTECTED] [mailto:gimp- [EMAIL PROTECTED] On Behalf Of David Gómez Sent: 07 January 2004 22:04 To: Sven Neumann Cc: Gimp-devel Subject: Re: [Gimp-developer] Dithering Hi Sven ;), The GIMP display canvas uses the dithering routines from GdkRGB which is probably what you are refering to. Yes i was referring to GdkRGB dithering, but it seems that was not the cause of the problem, as i said in my previous mail, and i was wrong thinking that was caused by gimp dithering implementation. Thanks, -- David Gómez The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
Hi, Austin Donnelly [EMAIL PROTECTED] writes: That's because the screen display code doesn't smooth the image when it scales it, for speed reasons. Dedicated viewing programs can afford to do a better job showing the image because they won't be re-drawing it quite so often (imaging panning around the image while editing it - you'd like that to be fast, right?) Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:51:17PM +0100, Marc A. Lehmann wrote:
On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh [EMAIL PROTECTED] wrote:
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
Well, troubling to me would be the fact that a int is not the same as
a void *, so this very example is a bit strange and could likely cause
problems on 64-bit (or else) architectures, but that is, of course, not
the main point.
You misread. To explain further:
void set_null (void **p)
{
*p = NULL;
}
void foo (void)
{
int *i;
set_null ((void **) i);
}
Which basically sets i = NULL. I don't see how this can be a problem on a
64-bit architectures, since pointers to all types are the same size.
gimp actually only does this with external functions, like:
voidg_object_add_weak_pointer (GObject*object,
gpointer *weak_pointer_location);
or
gboolean g_module_symbol(GModule *module,
const gchar *symbol_name,
gpointer *symbol);
Perhaps the API should be fixed, I dunno.
I don't know the real case this is based on, but I'd wonder what this code
is supposed to do then. Please note that the warning will not happen when
you cast to a void *, since the pointers might alias then.
Sure, I know ways of working it around it. My preferred fix is not to
cast to a void *, but use a temporary void * and assign back, since that
adds some type safety instead of casting.
Legally, the compiler could cache the contents of i in a register before
and after the call, because foo is not allowed to change it's value. (And
I might guess that foo will not do that, but it's equally hard to see this
as a compiler as it is for a human, so the warning is IMnsO justified).
Ah, that answers my question, thanks.
It's unlikely that this will happen with gcc = 3.5, which is, IMHO,
a viable platform to tie oneself to, but there are no guarentees that
this won't happen in more complicated cases, with other (less or more
intelligent) compilers or with future gcc versions.
It's hard to judge from his example, but right now it's difficult for
me to imagine a valid use for the above that couldn't easily be written
correctly.
To repeat it: I am quite certain that the above example will simply work
for quite some time in the future, because of some gcc assumptions about
pointers that are difficult to change but make no good otimized code.
Perl does similar pointer castings and has opted the safe way by simply
using -fno-strict-aliasing to compile itself at all times, after being
bitten once.
That might be easier then going through all the code and fixing it, and
will of course silence the warning. Right now, it doesn't make much of a
difference in generated code with gcc, as it is not very good at taking
advantage of (no-) aliasing yet, but this is a hot area in gcc, since
exploiting aliasing rules allow a great deal of optimizations in typical
numerical code.
Well, one problem is that flagging every violation like this makes people
tend to ignore the warning, which means real problems which affect gcc's
alias analysis *now* are likely to be overlooked, or heavy handed solutions
like -fno-strict-aliasing put in. It'd be much nicer if this warning didn't
trigger for function parameters (except with -pedantic) until gcc was closer
to doing the alias analysis that would manifest a problem.
As it stands, right now the warning mainly confuses people. It doesn't help
that the aliasing rules aren't spelled out anywhere in the gcc docs. I was
actually skeptical that gcc might be buggy in this regard, until I dug up
the appropriate bits of the standard that say what's going on.
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-data-extras update
Hi all, I was a little bored after lunch, so I updated the configure.in of gimp-data-extras to work with the 1.3 releases. For those who want to install these with an old 1.2 gimp, the branch gimp-1-2 was created. To get the extra brushes, patterns and gradients that were collected all those years ago, cvs co the gimp-data-extras repository on cvs.gnome.org, run autogen.sh and then make install. Those of you using anonymous CVS will have to wait a while. Those of you who don't want to go messing in CVS will get a tarball soon. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
