tcl-mac

[MACTCL] Partial PNG transparency not working in Cocoa Tk

[Linus N. <li...@fa...>]

Hi all,

I’m trying to move our application over from Carbon based Tcl/Tk (8.5.4) to any of the Cocoa versions (8.5.13 or 8.6.1) in order to get Retina text, 64 bit support, future proof, etc.
One show stopper problem I’m having is that tk “images” don’t seem to render partial transparency (where pixels are 1-99% transparent).
Here’s a screenshot of the result I get, where I show a “label -image”, a “label -bitmap” and “canvas image” with the same transparent png image. Only the bitmap label works, the others are wrong:
https://dl.dropboxusercontent.com/u/12145205/alphatest_fail.png

Does anyone have any tips on how to get this working? It works fine on the old Carbon based Tk, using the tkpng extension. It also works fine on 8.6.1 on *Windows*.
I wish it was as easy as just using “-bitmap” based labels all the time, but we at least really need images to work in canvas as well (bitmap does not work there as far as I know).

Here are replication steps:
- Download and install ActiveTcl 8.6.1
- Go to http://www.w3.org/Graphics/PNG/inline-alpha.html and drag the test png image to your Desktop
- Save the code below to a file (for example “alphatest.tcl on your desktop).
- Open Wish.app for Tcl 8.6.1 and “Source…” alphatest.tcl
- Happens: The image based label and image in canvas are wrong, but the bitmap based label works.

# alphatest.tcl
#-----------------
set png_path "~/Desktop/alphatest.png"

wm geometry . 400x900

::tk::mac::iconBitmap test_png 380 287 -imageFile $png_path
image create photo test_png -format png -width 380 -height 287 -file $png_path

# LABEL BASED ON "image" - does not handle partial transparency well
#-----------------------
set l .image_label
label $l -image test_png
place $l -x 10 -y 10 -anchor nw

# LABEL BASED ON "bitmap" - works
#-----------------------
set l2 .bitmap_label
label $l2 -bitmap test_png
place $l2 -x 10 -y 300 -anchor nw

# IMAGE IN CANVAS (BASED ON "image") - does not handle partial transparency well
#-----------------------------------
set c .c
canvas $c -width 500 -height 310 -bg white
place $c -x 10 -y 600 -anchor nw
$c create image 10 10 -image test_png -anchor nw

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

[Wojciech K. <woj...@ko...>]

Hi,

I have recently noticed it myself and done some investigation on the
issue. Here is some summary:

- happens on OS X 10.9 only - does not happen on 10.8 and below (also,
transparency works fine on all other systems and all other OS X
versions, so I suspect this is a change in OS X 10.9 that broke it)

- happens with latest Tcl/Tk from fossil, latest ActiveTcl

- happens with both tkpng and Img

- I can also confirm it only happens with Cocoa, not Carbon

So this is definitely an issue with Tk.

As I am not a Cocoa/Tk expert, that is as far as I went. For the
affected code I simply created PNG images with 0%/100% transparency
and use transparent images for other OSes for now, at least until this
is resolved.


2013/11/29 Linus Nyberg <li...@fa...>:
> Hi all,
>
> I’m trying to move our application over from Carbon based Tcl/Tk (8.5.4) to
> any of the Cocoa versions (8.5.13 or 8.6.1) in order to get Retina text, 64
> bit support, future proof, etc.
> One show stopper problem I’m having is that tk “images” don’t seem to render
> partial transparency (where pixels are 1-99% transparent).
> Here’s a screenshot of the result I get, where I show a “label -image”, a
> “label -bitmap” and “canvas image” with the same transparent png image. Only
> the bitmap label works, the others are wrong:
> https://dl.dropboxusercontent.com/u/12145205/alphatest_fail.png
>
> Does anyone have any tips on how to get this working? It works fine on the
> old Carbon based Tk, using the tkpng extension. It also works fine on 8.6.1
> on *Windows*.
> I wish it was as easy as just using “-bitmap” based labels all the time, but
> we at least really need images to work in canvas as well (bitmap does not
> work there as far as I know).
>
> Here are replication steps:
> - Download and install ActiveTcl 8.6.1
> - Go to http://www.w3.org/Graphics/PNG/inline-alpha.html and drag the test
> png image to your Desktop
> - Save the code below to a file (for example “alphatest.tcl on your
> desktop).
> - Open Wish.app for Tcl 8.6.1 and “Source…” alphatest.tcl
> - Happens: The image based label and image in canvas are wrong, but the
> bitmap based label works.
>
> # alphatest.tcl
> #-----------------
> set png_path "~/Desktop/alphatest.png"
>
> wm geometry . 400x900
>
> ::tk::mac::iconBitmap test_png 380 287 -imageFile $png_path
> image create photo test_png -format png -width 380 -height 287 -file
> $png_path
>
> # LABEL BASED ON "image" - does not handle partial transparency well
> #-----------------------
> set l .image_label
> label $l -image test_png
> place $l -x 10 -y 10 -anchor nw
>
> # LABEL BASED ON "bitmap" - works
> #-----------------------
> set l2 .bitmap_label
> label $l2 -bitmap test_png
> place $l2 -x 10 -y 300 -anchor nw
>
> # IMAGE IN CANVAS (BASED ON "image") - does not handle partial transparency
> well
> #-----------------------------------
> set c .c
> canvas $c -width 500 -height 310 -bg white
> place $c -x 10 -y 600 -anchor nw
> $c create image 10 10 -image test_png -anchor nw
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

[Kevin W. <kw...@co...>]

On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
> transparency works fine on all other systems and all other OS X
> versions, so I suspect this is a change in OS X 10.9 that broke it)
>
> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>
> - happens with both tkpng and Img
>
> - I can also confirm it only happens with Cocoa, not Carbon
>
> So this is definitely an issue with Tk.

I'm not certain where to start with this. I've seen reports in Apple's 
dev forums about wonky color calibration in Mavericks (sRGB is no longer 
accurately rendered in many contexts, which is causing headaches for 
graphics shops), yet Linus reports that images created with the 
tk::mac::IconBitmap command (which is just a thin wrapper around various 
NSImage methods) work just fine. NSImage is itself an opaque wrapper 
around many, many different things.

If the issues with alpha channel rendering are based in the system 
changes in Mavericks, I am not optimistic about fixing them...it does 
not seem like a good idea to try to special-case image code in the Img, 
TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
start here.)

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

[Linus N. <li...@fa...>]

Hi and thank both of you for replying.

I can confirm that the same thing works fine on Mac OS X Lion.
Unfortunately, Mavericks is not going away any time soon, and it’s a little scary that we appear to be the only ones trying to show transparent icons on the latest Mac OS X.

I now managed to download and compile the sources for Tcl/Tk 8.6.1 and using printf:s around the code I managed to track down the problem:
- The way Tk composits photo images with alpha by creating an image of the background window and manually blending that image with the transparent image (see TkImgPhotoDisplay() in tkImgPhInstance.c).
- When it fails to create the image of the background image, it simply draws the image without alpha (see TkImgPhotoDisplay() @ “We failed to get the image so draw without blending alpha. It's the best we can do”).
- The problem is in case is that exactly that fails.
- The reason for the failure is inside XCopyArea() in tkMacOSXDraw.c. There we can find this code:
	NSView *view = TkMacOSXDrawableView(srcDraw); 
	NSWindow *w = [view window];
	NSInteger gs = [w windowNumber] > 0 ? [w gState] : 0;

… and gs becomes 0, which makes the method return prematurely.
When googling for NSWindow gState, I found this:
https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/#//apple_ref/doc/uid/TP30000741-CH2-SW51
where it states:
> Beginning in Mac OS X 10.9 -[NSView allocateGState] and -[NSView releaseGState] are no ops. These methods were seldom used. Additionally, methods that relied on the side effects of these methods, specifically -[NSView gState] and -[NSWindow gState] will now always return 0.


That would explain it, I think… But I don’t know what “gState” is and I don’t know how to solve it.
Any ideas??

Best regards,

Linus

On 3 dec 2013, at 15:40, Kevin Walzer <kw...@co...> wrote:

> On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
>> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
>> transparency works fine on all other systems and all other OS X
>> versions, so I suspect this is a change in OS X 10.9 that broke it)
>> 
>> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>> 
>> - happens with both tkpng and Img
>> 
>> - I can also confirm it only happens with Cocoa, not Carbon
>> 
>> So this is definitely an issue with Tk.
> 
> I'm not certain where to start with this. I've seen reports in Apple's 
> dev forums about wonky color calibration in Mavericks (sRGB is no longer 
> accurately rendered in many contexts, which is causing headaches for 
> graphics shops), yet Linus reports that images created with the 
> tk::mac::IconBitmap command (which is just a thin wrapper around various 
> NSImage methods) work just fine. NSImage is itself an opaque wrapper 
> around many, many different things.
> 
> If the issues with alpha channel rendering are based in the system 
> changes in Mavericks, I am not optimistic about fixing them...it does 
> not seem like a good idea to try to special-case image code in the Img, 
> TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
> start here.)
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

[Adrian R. <adr...@gm...>]

From what I can tell the gstate is just a shortcut for avoiding creating a new one by focusing the view.  So it should be possible to use:

[view lockFocusIfCanDraw]
draw, calling the NSCopyBits with NSNullObject instead of gstate
[view unlockFocus]

But it might not be that simple — I don’t fully understand the NSGraphicsContext-related calls below.



On 2013.12.6, at 19:58, Linus Nyberg <li...@fa...> wrote:

> Hi and thank both of you for replying.
> 
> I can confirm that the same thing works fine on Mac OS X Lion.
> Unfortunately, Mavericks is not going away any time soon, and it’s a little scary that we appear to be the only ones trying to show transparent icons on the latest Mac OS X.
> 
> I now managed to download and compile the sources for Tcl/Tk 8.6.1 and using printf:s around the code I managed to track down the problem:
> - The way Tk composits photo images with alpha by creating an image of the background window and manually blending that image with the transparent image (see TkImgPhotoDisplay() in tkImgPhInstance.c).
> - When it fails to create the image of the background image, it simply draws the image without alpha (see TkImgPhotoDisplay() @ “We failed to get the image so draw without blending alpha. It's the best we can do”).
> - The problem is in case is that exactly that fails.
> - The reason for the failure is inside XCopyArea() in tkMacOSXDraw.c. There we can find this code:
> 	NSView *view = TkMacOSXDrawableView(srcDraw); 
> 	NSWindow *w = [view window];
> 	NSInteger gs = [w windowNumber] > 0 ? [w gState] : 0;
> 
> … and gs becomes 0, which makes the method return prematurely.
> When googling for NSWindow gState, I found this:
> https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/#//apple_ref/doc/uid/TP30000741-CH2-SW51
> where it states:
>> Beginning in Mac OS X 10.9 -[NSView allocateGState] and -[NSView releaseGState] are no ops. These methods were seldom used. Additionally, methods that relied on the side effects of these methods, specifically -[NSView gState] and -[NSWindow gState] will now always return 0.
> 
> That would explain it, I think… But I don’t know what “gState” is and I don’t know how to solve it.
> Any ideas??
> 
> Best regards,
> 
> Linus
> 
> On 3 dec 2013, at 15:40, Kevin Walzer <kw...@co...> wrote:
> 
>> On 11/29/13, 3:58 AM, Wojciech Kocjan wrote:
>>> - happens on OS X 10.9 only - does not happen on 10.8 and below (also,
>>> transparency works fine on all other systems and all other OS X
>>> versions, so I suspect this is a change in OS X 10.9 that broke it)
>>> 
>>> - happens with latest Tcl/Tk from fossil, latest ActiveTcl
>>> 
>>> - happens with both tkpng and Img
>>> 
>>> - I can also confirm it only happens with Cocoa, not Carbon
>>> 
>>> So this is definitely an issue with Tk.
>> 
>> I'm not certain where to start with this. I've seen reports in Apple's 
>> dev forums about wonky color calibration in Mavericks (sRGB is no longer 
>> accurately rendered in many contexts, which is causing headaches for 
>> graphics shops), yet Linus reports that images created with the 
>> tk::mac::IconBitmap command (which is just a thin wrapper around various 
>> NSImage methods) work just fine. NSImage is itself an opaque wrapper 
>> around many, many different things.
>> 
>> If the issues with alpha channel rendering are based in the system 
>> changes in Mavericks, I am not optimistic about fixing them...it does 
>> not seem like a good idea to try to special-case image code in the Img, 
>> TkPNG, and 8.6 core, I would think. (Nor would I even know where to 
>> start here.)
>> 
>> --Kevin
>> 
>> -- 
>> Kevin Walzer
>> Code by Kevin/Mobile Code by Kevin
>> http://www.codebykevin.com
>> http://www.wtmobilesoftware.com
>> 
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT 
>> organizations don't have a clear picture of how application performance 
>> affects their revenue. With AppDynamics, you get 100% visibility into your 
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK 
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk_______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Partial PNG transparency not working in Cocoa Tk

[Kevin W. <kw...@co...>]

Adrian and Linus,

On 12/7/13, 9:43 AM, Adrian Robert wrote:
>  From what I can tell the gstate is just a shortcut for avoiding creating a new one by focusing the view.  So it should be possible to use:
>
> [view lockFocusIfCanDraw]
> draw, calling the NSCopyBits with NSNullObject instead of gstate
> [view unlockFocus]
>
> But it might not be that simple — I don’t fully understand the NSGraphicsContext-related calls below.

Thank you for these suggestions. I've been doing some digging into 
gState and can't quite figure out what purpose it serves.  I don't think 
there's an equivalent CoreGrpahics call that we can substitute in for it 
(I've been looking at it from that angle). I'll give this approach a try 
and see if I can make any progress. More in a few days, hopefully.

What a headache! Some might call the Win32 and Xlib API's may be 
moribund, but I prefer Debian-speak here: "stable." Grumble, grumble, 
grumble...

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com