Re: [MACTCL] Canvas postscript...

[Jim I. <ji...@ap...>]

Daniel,

Thanks for looking at this!

I applied your patch to TOT, and images with transparency now work fine  
on labels.  But for some reason, it looks like they don't work on the  
canvas at all.  If you get the test package that Jeff referred to:

http://sf.net/tracker/?group_id=12997&atid=112997&func=detail&aid=809157

Get the alpha-test3.tar.gz.  When I ran this in your patched Wish, I  
get nothing.  The postscript does show all the buttons, though there is  
some odd striping in the images, and the transparency doesn't look very  
good.

OTOH, if you do (in the same Wish) something like:

% .c itemconfigure 3
{-activeimage {} {} {} {}} {-anchor {} {} center nw} {-disabledimage {}  
{} {} {}} {-image {} {} {} image1} {-state {} {} {} {}} {-tags {} {} {}  
{}}
% toplevel .t
.t
% label .t.l -bg orange -image image1

The red button appears perfectly, with the shadow blending nicely into  
the orange background of the label...

Not sure why this is.   Your approach seems fine to me, there must be  
just some goof somewhere or other...

I can't look at this any more today, but I will try to look at it  
tonight.

Jim

On Feb 19, 2004, at 10:42 AM, Daniel A. Steffen wrote:

> Jim,
>
> On 18/02/2004, at 14:10, Jim Ingham wrote:
>
>> The text anti-aliasing makes this look a little strange, but the  
>> attached patch gets the postscript mostly right for copying windows.   
>> I haven't done it for offscreen worlds, yet.  Jeff, does this help in  
>> the case you were worrying about?
>
> I had a patch very similar to this when I looked at the tk photo alpha  
> compositing bug (#809157) but it turned out that just fixing XGetImage  
> is not sufficient, as the resulting XImages could not be pushed back  
> on screen by XPutImage...
>
> After a fair bit of pain, I think I've nailed the problem now, both  
> photo alpha and convas ps work perfectly, c.f.
>
> 	http://rutherglen.ics.mq.edu.au/~steffen/tcltk/tk_bug_809157/ 
> XGetPutImage-HEAD.patch
>
> test files for both cases are also in
> 	http://rutherglen.ics.mq.edu.au/~steffen/tcltk/tk_bug_809157/
> I'd appreciate if others tested the patch with these...
>
> The were a number of issues involved, all related to the QDPixMaps we  
> get from NewGWorld (via Tk_GetPixmap) and which are CopyBits'd into in  
> XGetImage.
> After that CopyBits, the QDPixMap is nothing like the QDPixMaps we  
> construct by hand in XPutImage from an ARGB buffer; which is why  
> XPutImage was failing miserably to copy such XImages from XGetImage  
> back to screen. c.f. screenshot
> 	http://rutherglen.ics.mq.edu.au/~steffen/tcltk/tk_bug_809157/old/ 
> HEAD.pdf
>
> Another issue with these QDPixMaps/GWorlds is that for such QDPorts,  
> GetCPixel/SetCPixel return/take 16 bit color values instead of 8 bit  
> values as is the case for ordinary ARBG QDPixMaps. This obviously  
> makes XGetPixel/XPutPixel fail...
>
> The solution I've now come up with is to track which XImages come from  
> XGetImage and handle them specially, to this end I use the unused  
> XImage obdata field, which now stores a reference to the Pixmap (i.e.  
> MacDrawable) underlying the XImage when applicable, and is NULL  
> otherwise.
>
> In XPutImage, XImages with attached Pixmap are then copybits'd  
> directly from the associated GWorld; and these XImages also undergo  
> 8bit shifting in XGetPixel/XPutPixel.
>
> This works well as long as all creators of XImages with underlying  
> Pixmaps coming from Tk_GetPixmap respect this obdata convetion...
> in Tk, the only such creator is XGetImage at present, but there might  
> be Tk extensions that use  Tk_GetPixmap & XCreateImage.
> (My Tix port does someting similar for subregion drawing, but uses  
> Pixmaps directly rather than creating XImages on top, which avoids the  
> issue.) Of course any such Tk extensions are not working now anyway,  
> so I don't think this will create any new problems...
>
> Let me know if you think this is a reasonable solution to the problem  
> and if you are ok with the patch, it would be good if we could get  
> this into 8.4.6, I'll look at backporting the HEAD patch to  
> core-8-4-branch tomorrow
>
> Cheers,
>
> Daniel
>
> -- 
> ** Daniel A. Steffen     **  "And now for something completely
> ** Dept. of Mathematics  **   different"    Monty Python
> ** Macquarie University  **  <mailto:st...@ma...>
> ** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>
>
>
--
Jim Ingham                                   ji...@ap...
Developer Tools
Apple Computer