When using "partial transparency of images with non-
trivial alpha channels", the renderer always assumes a
grey background. This means that if the image has any
areas that are partially transparent instead of fully
transparent they will be rendered as grey pixels. This
precludes using any shape such as a rounded edge,
circles, ovals, triangles, polygons, etc (anything other
than a normalized, non-rotated rectangle) that require
anti-aliasing in an image as the edges will appear jagged
with grey pixels instead of smooth and blended with the
background pixels. The correct behaviour is to instead
sample the underlying background pixel and combine it
with the partially transparent pixel of the foreground
image to create a new "result" pixel. According to dkf
the issue appears to be a bug in the renderer code
in "tkImgPhoto.c".
Logged In: YES
user_id=79902
GPStaplin is working on a fix for this in selected visual
types (those without palettes!)
Logged In: YES
user_id=72656
attaching new patch which rewrites GPS's stuff to scale back
the a much simpler alpha blend. It always blends against the
original image and works correctly for 16bpp (with
tkWinImage.c patch also attached). Needs to be tested on
OS X, especially with 16bpp.
Logged In: YES
user_id=72656
I should note that the one oddity I see with this is for
Windows 16bpp displays, when the x and/or width to display
is at the edge (clipped) and odd, the image can get slanted.
Logged In: YES
user_id=72656
attached is a modification of GPS's tests that display several
alpha transparent images. test against 16bpp and 24+bpp
(and 8bpp - you should see no use of blending).
Logged In: YES
user_id=72656
minor correction in patch for XGetImageZPixmap to handle
odd width images by letting XCreateImage calc the line width
from the bitmap_pad. This makes 16bpp work right on
Windows.
Logged In: YES
user_id=72656
3rd gen patch that uses shift/mask info from the visual. This
should work across LE and BE machines and X server
variations. It's more compute intensive for unix.
Logged In: YES
user_id=72656
added new test files that have more clear images on what
one should see.
latest test files for clarity
Logged In: YES
user_id=79902
Need to call ToggleComplexAlphaIfNeeded() (or otherwise
toggle the COMPLEX_ALPHA bit) from inside Tk_PhotoPutBlock
and Tk_PhotoPutZoomedBlock, but might it be sufficient to
postpone computing that until idle?
Logged In: YES
user_id=79902
Aside from that, it looks good. Especially when I run two
identical tests side-by-side where one is in an 8-bit window
and the other is in a 24-bit window (one of the few things
that an SGI is really good at!) I shan't post the code I'm
using to do the test here, since it depends on a lot of
extra instrumentation code that I'm still thinking about.
Logged In: YES
user_id=79902
Hmm. Trying out a bit further, I find that you've got 16bpp
as the split-point between the two renderers. Wouldn't it
be better to use 15 but then only if the visual isn't
pseudocolor (or some other colormapped visual type?) And we
can of course support greyscale visuals completely even if
they are only 8 bits deep...
Logged In: YES
user_id=79902
Here's a helpful script (customize to suit!):
package require Img
set i 0
image create photo foo -file yourSampleImage.png
foreach visual [winfo visualsavailable .] {
set f [frame .f$i -visual $visual]
pack $f
label $f.l -text $visual -image foo -compound right
pack $f.l
}
Logged In: YES
user_id=72656
variant #6 that has somewhat working 16bpp code for unix. I
don't think this is 100% for 16bpp. It also simplifies the
ALPHA_BLEND macro.
Logged In: YES
user_id=72656
7 is the lucky number. Attached is a patch that should work
for 15bpp+ screens across the board. Needs OS X testing,
and of course more testing everywhere else.
Logged In: YES
user_id=79902
Assigning to Jeff as he seems to be taking more of a lead in
this one.
Logged In: YES
user_id=72656
fixed for 15bpp+ on Windows/Unix, but not OS X.