Re: [Gimp-developer] Solaris 64bit compile
Sven Neumann [EMAIL PROTECTED] wrote:
__u32 __rb = (((color.r)16) | (color.b));
__u32 __g = ((color.g)8);
switch (a) {\
case 0xff: *(d) = (0xff00 | __rb | __g); \
case 0: break; \
default: {\
__u32 pixel = *(d);\
__u16 s = (a)+1;\
register __u32 t1,t2; \
t1 = (pixel0x00ff00ff); t2 = (pixel0xff00); \
pixel = __rb-t1)*s+(t18)) 0xff00ff00) + \
((( __g-t2)*s+(t28)) 0x00ff)) 8; \
*(d) = pixel;\
}\
}
if you think this looks ugly, you should have a look at the same
function for RGB16 and RGB15 ;-)
I don't think they are that bad --- the readability of the above code
merely suffers from a pollution of backslashes and underscores. But the
general principle is useful and it's not hard to do parallel saturating
additions and subtractions without any branches at all, just using bit
fiddling.
Many modern architectures can do better with vector instructions but
generic fallback code is of course always needed
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gdk_set/get_use_xshm()
Hi Owen, Owen Taylor [EMAIL PROTECTED] writes: The GIMP currently does something a bit peculiar - it calls gdk_get_use_xshm() and then passes the values it gets from this to plugins, which call gdk_set_use_xshm(). I suppose the reasoning here is to propagate the command line --no-xshm to each plugin. If GTK+ is autodetecting the value of gdk_use_xshm, as it normally does, then the plugins could do that themselves just as well. What GIMP does is asking GDK if it uses shm (no matter if a commandline option was given) and passing this boolean to plug-ins. The plug-in then switches off GDK shm usage (also without looking at the old vale) if it was passed shm==FALSE from the main app. (plug-ins never try to explicitly switch it on) What I'd like to do is one or more of: - Make gdk_set/get_use_xshm() correspond exactly to the command line option, instead of a mix of the command line option and what has been autodetected so far. - Deprecate gdk_set/get_use_xshm(). - Remove the --no-xshm command line option Yes, please :) I believe that the problems that --no-xshm was added to deal with have most or all been fixed now and represented bugs in the GTK+ shm code. It really makes little sense to me to have a command line option to enable a bug workaround ... I doubt people want to type gimp --no-xshm all the time, so I suspect that if we needed a way of enabling a workaround for this, as an environment variable would make more sense. Do people use this command line option? Is my understanding of what the GIMP is doing correct? I don't know if people use it but some time ago (before GIMP 1.2) I fixed it to make plug-ins follow the main app's shm usage policy. It always looked as a crude hack to me and I fixed it without knowing what it is exactly used for or if it worked still/better after my fix. BTW, we are about to strip every bit of GLIB/GDK/GTK compat/deprecated/broken stuff from CVS GIMP, so please don't stick with antique code just because GIMP uses it (we're even removing gtk_signal_* and friends, so please just break GIMP, we will fix it to use GTK's new APIs :-) ciao, --M - no compat cruft - itch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Solaris 64bit compile
Hi, Mattias Engdegård [EMAIL PROTECTED] writes: I don't think they are that bad --- the readability of the above code merely suffers from a pollution of backslashes and underscores. I took this code out of a macro and forgot to remove the backslashes. Also we'd use different types since glib defines guint8, guint16 and guint32. I choose not to show off the code for RGB16 and RGB15 since the masks and shifting values used there make the code hard to understand, while the RGB32 and ARGB cases are more obvious. Also fortunately, we don't do RGB16 in gimp. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] suggestion for color to alpha
Rebecca J. Walter [EMAIL PROTECTED] writes: it might be useful if the color to alpha filter could a) interact with That reminds me: I'd like to use the color to alpha filter for chroma-keying. That is, stand the subject in front of a blue screen and use color-to-alpha to remove all the blue. However, the filter removes too much blue -- the resulting colour is as saturated as possible, even if the original colour wasn't so saturated. I'm thinking that it would be handy if the color-to-alpha had a preview and slider that went from 0 to 1, where 0 = do nothing and 1 = current behaviour and 0.5 gives a result half way between that for 0 and 1. Does this seem useful? Is there a better way to do this? just a thought. no, i can't prrogram it myself. I can program my idea if folks are interested. Tim ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
