From: Geoff B. <ge...@mr...> - 2006-05-04 12:07:29
|
Hi, I have encountered an unusual problem. Using TkImg to display png images on widgets, I have found that certain images will not display on buttons, despite being displayed correctly on labels. This does not occur for all pngs. Here is some example code to illustrate the problem: package require Img 1.3 image create photo file16x16 -data "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QAAAB5AACiY+igAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1gQNDQMUNnY/YgAAAB10RVh0Q29tbWVudABDcmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAABLklEQVQ4y42Tv0rEQBDGfzlU7iV8BgvRQq44JVpZ3psIVoKYysexsNATJRwcWNpcZ2thJ4p/bkPms0hu3ezF6MDshGHmy3zfziYAw5FEbVKBrMCsQKqjOcwK9gZ9zk/WE2IbjqQvVf4p6UPSu6Q3Sa+SXiRtHcy0mT7o+OxRYW+v/q8/BRhQ1tG7Oa5vNhjnzxydztQAMJv7wqXGBag50t0pVjrGd09MJhMBrAAVR/qNKcJpBFzdbvvv/cEleX6PBzBzjeKw2SIgA6x0XgMPEBeqpVkBnV8BukB8PgZQRMFaaBAJ2pygdJ3NS3n7hwbWoUMrQDyuujRp06DsuMKFly0T9AgSatvAYEMVrHVEYU66cxG9wKKiZgUWvtA6wuoPwGx6mGRZJv60BFirvbJvHho7WU00oXsAAAAASUVORK5CYII=" image create photo disk16x16 -data "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1gEKETQfcairAwAAAB10RVh0Q29tbWVudABDcmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAABHklEQVQ4y62TPU7DQBBG33gtD61vgFL4AtyAmjaRoIY0iJJ+kbgCTRoKCqTkApwllzBSikhkxkvh2FJIAEcwW+ysdufpm5+FP5oAVGWcA+Mj4hbLOk76U1XGdDFK6WKUUv1ep9Vqldbrddp8bFJqmtRZ96YqY5pOp3OA/CvazZEkCCACOOR5fkjF+CDAzNpI7wiCiBBCOJjLvgJvkMwQAXFp9+2CbAjAdoJEBMRaRRQDAI0jLr38rlfS+b8B7s5Pj5qDPcDV4yuqihYFeqIUqmih5HlOnJwNq8Hz/SUAt09vZMEJmQ3vgpnt+CEELGQEHwpwZxJfUFXcFAstxIP/CFgs64cxwM11/LZgVdnfLbpJ7Huzne3BH2o2mwn/YZ88Om+hLP9jrQAAAABJRU5ErkJggg==" label .file_label -image file16x16 label .disk_label -image disk16x16 button .file_button -image file16x16 button .disk_button -image disk16x16 grid .file_label .disk_label grid .file_button .disk_button The png image "file16x16" displays correctly on labels and buttons, but "disk16x16" only displays on the label, with the button being blank (but sized correctly for a 16x16 image). The problem remains when png files are used rather than png image data as a string. This problem occurs under Aqua using tk 8.4.11 with TkImg 1.3. I have also reproduced this with tk 8.4.13 (same TkImg installation). On another machine with tk 8.4.7 the test script actually causes a segmentation fault: usr/bin/wish8.4: line 2: 3095 Segmentation fault "$(dirname $0)/../../System/Library/Frameworks/Tk.framework/Versions/8.4/Resources/Wish Shell.app/Contents/MacOS/Wish Shell" "$@" The above script displays all images as expected using tk 8.4.11 on linux, and using tk 8.4.1 under X11 on Mac Os X. I'd be interested to hear if anyone else gets the same results, or has any suggestions for a workaround. Also, if anyone can identify exactly what it is about the disk16x16 png that causes it to fail while file16x16 works (I have several other examples of working and failing images), then I would love to hear about it! I posted to comp.lang.tcl but have had no replies saying they also had a problem. I had one reply saying it worked fine, but I'm not sure which version of tk that was with. http://groups.google.co.uk/group/comp.lang.tcl/tree/browse_frm/thread/a5194f85d94e0c4e/bcc9dbddb4b9773e?rnum=1&q=png+mac+os+x&_done=%2Fgroup%2Fcomp.lang.tcl%2Fbrowse_frm%2Fthread%2Fa5194f85d94e0c4e%2F8d004bf24fdd0c60%3Fq%3Dpng+mac+os+x%26rnum%3D1%26#doc_bcc9dbddb4b9773e Thanks in advance for any replies, Geoff. |
From: Mats B. <ma...@pr...> - 2006-05-04 13:03:22
|
I've had a lot of problems with latest TkIMG since its png importer crashes my coccinella app. All platforms. I'm using an older Tkimg that works but otherwise using TkPNG. Reported at: http://sourceforge.net/tracker/index.php?func=detail&aid=1294387&group_id=52039&atid=465492 Mats |
From: Jeff H. <je...@ac...> - 2006-05-09 23:38:02
|
Mats Bengtsson wrote: > I've had a lot of problems with latest TkIMG since its png=20 > importer crashes my coccinella app. All platforms. I'm using=20 > an older Tkimg that works but otherwise using TkPNG. Reported=20 > at:=20 > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1294387&grou= p_id=3D5203 9&atid=3D465492 BTW, I was able to repro Geoff's PNG ok on label but not on buttons = issue with ActiveTcl 8.4.13. However, the report above seems to involve a bit more = than a simple script ... is it just the one PNG that can trigger the crash? = I can look into it if we can narrow it down to a smaller snippet. Jeff |
From: Mats B. <ma...@pr...> - 2006-05-10 07:19:53
|
Jeff Hobbs wrote: > Mats Bengtsson wrote: >> I've had a lot of problems with latest TkIMG since its png >> importer crashes my coccinella app. All platforms. I'm using >> an older Tkimg that works but otherwise using TkPNG. Reported >> at: >> > http://sourceforge.net/tracker/index.php?func=detail&aid=1294387&group_id=5203 > 9&atid=465492 > > BTW, I was able to repro Geoff's PNG ok on label but not on buttons issue with > ActiveTcl 8.4.13. However, the report above seems to involve a bit more than > a simple script ... is it just the one PNG that can trigger the crash? I can > look into it if we can narrow it down to a smaller snippet. > I can add some recent info. I thought I was safe running an older libpngtcl1.0.so (with same name ?) since it has worked fine all the time, but when I added tile-qt it started crashing on the very first create photo ::_img::0_buttonok -file /root/Coccinella/Src/coccinella/images/buttonok.png -format png Very strange. Using gdb on the core dump showed: (gdb) bt #0 0x4010959f in TclpAlloc () from /usr/local/ActiveTcl/lib/libtcl8.4.so Cannot access memory at address 0x40 ??? So I just throwed out libpngtcl1.0.so and tile-qt runs just fine. (BTW I believe tile-qt, is a very important extension for linux app developers!) Mats |
From: Jeff H. <je...@ac...> - 2006-05-10 17:41:41
|
Mats Bengtsson wrote: > I can add some recent info. I thought I was safe running an=20 > older libpngtcl1.0.so (with same name ?) since it has worked=20 > fine all the time, but when I added tile-qt it started=20 > crashing on the very first=20 > create photo ::_img::0_buttonok -file=20 > /root/Coccinella/Src/coccinella/images/buttonok.png -format png=20 > Very strange. Using gdb on the core dump showed: > (gdb) bt > #0 0x4010959f in TclpAlloc () from=20 > /usr/local/ActiveTcl/lib/libtcl8.4.so > Cannot access memory at address 0x40 >=20 > ??? > So I just throwed out libpngtcl1.0.so and tile-qt runs just=20 Like all the best bugs, I can repro this with AT 8.4.13.0, and if I just = use a debug build of Img, the bug disappears. :/ Memory corruption of some = sort. Jeff |
From: Geoff B. <ge...@mr...> - 2006-05-10 17:51:14
|
Thanks for the replies to my problem. Do I need to raise this a bug on sourceforge, or is it being addressed as part of Mats's problem? Thanks, Geoff. Jeff Hobbs wrote: > Mats Bengtsson wrote: > >>I can add some recent info. I thought I was safe running an >>older libpngtcl1.0.so (with same name ?) since it has worked >>fine all the time, but when I added tile-qt it started >>crashing on the very first >> create photo ::_img::0_buttonok -file >>/root/Coccinella/Src/coccinella/images/buttonok.png -format png >>Very strange. Using gdb on the core dump showed: >>(gdb) bt >>#0 0x4010959f in TclpAlloc () from >>/usr/local/ActiveTcl/lib/libtcl8.4.so >>Cannot access memory at address 0x40 >> >>??? >>So I just throwed out libpngtcl1.0.so and tile-qt runs just > > > Like all the best bugs, I can repro this with AT 8.4.13.0, and if I just use a > debug build of Img, the bug disappears. :/ Memory corruption of some sort. > > Jeff > |
From: Jeff H. <jeffh@ActiveState.com> - 2006-05-10 18:09:26
|
Geoff Battye wrote: > Do I need to raise this a bug on sourceforge, or is it being > addressed as part of Mats's problem? This is being addressed under Mats' report. It may be I can extract some extra info from valgrind, but it isn't working so far ... Jeff |
From: Jeff H. <jeffh@ActiveState.com> - 2006-05-10 18:56:45
|
Mats Bengtsson wrote: > > Mats Bengtsson wrote: > >> I've had a lot of problems with latest TkIMG since its png > >> importer crashes my coccinella app. All platforms. I'm using=20 > >> an older Tkimg that works but otherwise using TkPNG. Reported=20 > >> at:=20 > >> > > = http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1294387&grou= p > > _id=3D52039&atid=3D465492 > >=20 > > BTW, I was able to repro Geoff's PNG ok on label but not on buttons=20 > > issue with ActiveTcl 8.4.13. However, the report above seems to=20 > > involve a bit more than a simple script ... is it just the one PNG=20 > > that can trigger the crash? I can look into it if we can narrow it=20 > > down to a smaller snippet. >=20 > I can add some recent info. I thought I was safe running an=20 > older libpngtcl1.0.so (with same name ?) since it has worked=20 > fine all the time, but when I added tile-qt it started=20 > crashing on the very first=20 > create photo ::_img::0_buttonok -file=20 > /root/Coccinella/Src/coccinella/images/buttonok.png -format png=20 > Very strange. Using gdb on the core dump showed: > (gdb) bt > #0 0x4010959f in TclpAlloc () from=20 > /usr/local/ActiveTcl/lib/libtcl8.4.so > Cannot access memory at address 0x40 ... OK, I have some more info on this ... I noticed using valgrind on AT = 8.4.13 on Linux that I was getting png error bits from mixed AT and Coccinella = source binaries. I removed all the libraries that Coccinella had that were = repeated in AT (tile, snack, Img and vfs). I reran ... and no more crash. Something has been fixed, or something else is going wrong. Perhaps Coccinella is using pngtcl then? When running in tkcon, I see both = img::png and tkpng loaded, but I can force them to load in either order, and = still see no crashing. Mats - can you please confirm this? Geoff - this doesn't address your OS X png issue. That is peculiar, and = is related to the PNG data of the disk button somehow (changing the = ordering or creation still has only the disk16x16 affected). Jeff |
From: Mats B. <ma...@pr...> - 2006-05-11 06:31:36
|
Jeff Hobbs wrote: > > OK, I have some more info on this ... I noticed using valgrind on AT 8.4.13 on > Linux that I was getting png error bits from mixed AT and Coccinella source > binaries. I removed all the libraries that Coccinella had that were repeated > in AT (tile, snack, Img and vfs). I reran ... and no more crash. > > Something has been fixed, or something else is going wrong. Perhaps > Coccinella is using pngtcl then? When running in tkcon, I see both img::png > and tkpng loaded, but I can force them to load in either order, and still see > no crashing. > > Mats - can you please confirm this? > Yes. On ActiveState 8.4.12 distro. o If I keep the AT 8.4.12 and coccinella as is it crashes on the first png image. o If I remove the Img1.3 from AT then it runs. o If I keep Img1.3 in AT but remove Img1.3 (which is an older build I guess than the one in AT 8.4.12) and snack2.2 (just a random pick) from the coccinella, it runs as Jeff said. o If I keep Img1.3 in AT but remove only Img1.3 from coccinella it also runs. o If I then add back (older) Img1.3 to the coccinella it crashes again. o If I then remove Img1.3 from AT it runs. So however you turn, it indicates problems in Img1.3. Mats |
From: David Z. <kr...@kr...> - 2006-05-10 19:15:36
Attachments:
smime.p7s
|
Le 10 mai 06 =E0 01:37, Jeff Hobbs a =E9crit : > is it just the one PNG that can trigger the crash? I can > look into it if we can narrow it down to a smaller snippet. If you remove the alpha channel in disk16x16 it works again. I've =20 done this: % disk16x16 write ~/Desktop/disk16x16.png -format png % image create photo disk16x16 -file ~/Desktop/disk16x16.png ; # this =20= doesn't work I open disk16x16.png with Preview and save it as ~/Desktop/=20 disk16x16no.png without alpha channel, then : % image create photo disk16x16 -file ~/Desktop/disk16x16no.png ; # =20 this works Hope this will help. --=20 David Zolli kr...@kr... http://www.kroc.tk |
From: Jeff H. <je...@ac...> - 2006-05-10 19:44:37
|
David Zolli wrote: > Le 10 mai 06 =E0 01:37, Jeff Hobbs a =E9crit : > > is it just the one PNG that can trigger the crash? I can look into = it=20 > > if we can narrow it down to a smaller snippet. >=20 > If you remove the alpha channel in disk16x16 it works again. I've =20 > done this: >=20 > % disk16x16 write ~/Desktop/disk16x16.png -format png > % image create photo disk16x16 -file ~/Desktop/disk16x16.png=20 > ; # this =20 > doesn't work >=20 > I open disk16x16.png with Preview and save it as ~/Desktop/=20 > disk16x16no.png without alpha channel, then : >=20 > % image create photo disk16x16 -file ~/Desktop/disk16x16no.png ; # =20 > this works Yes, this helps. These are different paths, and I can now narrow down = the issue (it's in tkMacOSXDraw.c:TkPutImage, the image->obdata case). Jeff |
From: Geoff B. <ge...@mr...> - 2006-05-10 20:00:08
|
Jeff Hobbs wrote: > David Zolli wrote: >>If you remove the alpha channel in disk16x16 it works again. I've >>done this: <snip> > Yes, this helps. These are different paths, and I can now narrow down the > issue (it's in tkMacOSXDraw.c:TkPutImage, the image->obdata case). > > Jeff Yes, it appears to be images including semi-transparent pixels that cause problems. Here's an example with the original image that was causing problems, and a copy where I've deleted the semi-transparent pixels: package require Img 1.3 image create photo disk16x16 -data "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1gEKETQfcairAwAAAB10RVh0Q29tbWVudABDcmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAABHklEQVQ4y62TPU7DQBBG33gtD61vgFL4AtyAmjaRoIY0iJJ+kbgCTRoKCqTkApwllzBSikhkxkvh2FJIAEcwW+ysdufpm5+FP5oAVGWcA+Mj4hbLOk76U1XGdDFK6WKUUv1ep9Vqldbrddp8bFJqmtRZ96YqY5pOp3OA/CvazZEkCCACOOR5fkjF+CDAzNpI7wiCiBBCOJjLvgJvkMwQAXFp9+2CbAjAdoJEBMRaRRQDAI0jLr38rlfS+b8B7s5Pj5qDPcDV4yuqihYFeqIUqmih5HlOnJwNq8Hz/SUAt09vZMEJmQ3vgpnt+CEELGQEHwpwZxJfUFXcFAstxIP/CFgs64cxwM11/LZgVdnfLbpJ7Huzne3BH2o2mwn/YZ88Om+hLP9jrQAAAABJRU5ErkJggg==" image create photo disk_no_semi_transparency16x16 -data "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH1gUKEwEN1iRqUwAAAB10RVh0Q29tbWVudABDcmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAABDElEQVQ4y62TMU7EQAxFn+NRTJsbICHlAlwA0dOuBDWkQZTUpOAKNNtQbMEVOAUH4BJwADuhmCSwbBYFgUcjuxg/f9ke+KPJGNRV2y9Nen1rp7w0JtfVHQCbl3eSJlJKg1eQ/P7saGL0I6T4Tg+P4TrROR4xq6Jpmn5S8NXcPVcMhsqCiKCqs6AdQESHFI4ISEj2w5kRPAfwrSQRAfGsiHIBoAskZJI/zko+B/Yz4Ob08Fd7sAO4uH/CzLCyxA6M0gwrjZQS7ep4WQ8eb88BuH54ptBAC18+BXffilUV1wKNpYAIVu0GMyPccM2Q0NgPGNayB7i6bPc2rK7a6S+ckDdR5tZzia3Xa+E/7AO/wluLgUh4nQAAAABJRU5ErkJggg==" label .a -image disk16x16 label .b -image disk_no_semi_transparency16x16 button .c -image disk16x16 button .d -image disk_no_semi_transparency16x16 grid .a .b grid .c .d As before, it's only disk16x16 on buttons that cause the problem. Many thanks for your help. Geoff. |
From: Daniel A. S. <st...@ic...> - 2006-05-10 20:45:58
|
Jeff, On 11/05/2006, at 5:43, Jeff Hobbs wrote: > Yes, this helps. These are different paths, and I can now narrow > down the > issue (it's in tkMacOSXDraw.c:TkPutImage, the image->obdata case). I suspect what is going wrong is the copying of the image into the open QD picture used for the bevel button decoration, potentially related to this comment in SetupBevelButton: /* * TO DO - There is one case where XCopyPlane calls CopyDeepMask, * which does not get recorded in the picture. So the bitmap code * will fail in that case. */ it's possible tk's strategy of alpha-blending manually into the XGetImage of the bg may not work in this case anyway, as the native widget has probably not been drawn yet when the bg image is taken... Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** |
From: Jeff H. <je...@ac...> - 2006-05-10 20:49:37
|
Daniel A. Steffen wrote: > On 11/05/2006, at 5:43, Jeff Hobbs wrote: > > Yes, this helps. These are different paths, and I can now narrow > > down the > > issue (it's in tkMacOSXDraw.c:TkPutImage, the image->obdata case). > > I suspect what is going wrong is the copying of the image into the > open QD picture used for the bevel button decoration, potentially > related to this comment in SetupBevelButton: > /* > * TO DO - There is one case where XCopyPlane calls CopyDeepMask, > * which does not get recorded in the picture. So the > bitmap code > * will fail in that case. > */ > > it's possible tk's strategy of alpha-blending manually into the > XGetImage of the bg may not work in this case anyway, as the native > widget has probably not been drawn yet when the bg image is taken... Yes, I believe the latter is very much the issue. Any ideas? Jeff |
From: Michael K. <mi...@mu...> - 2006-05-10 21:00:14
|
Just wanted to point this out: https://sourceforge.net/tracker/?func=detail&aid=1155596&group_id=12997&atid=112997 This ticket deals with crashes with buttons and images with alpha on the Mac. I thought the crashing had been fixed, though, and now there was just a resizing issue. On Wed, 10 May 2006, Jeff Hobbs wrote: > Date: Wed, 10 May 2006 13:49:06 -0700 > From: Jeff Hobbs <je...@ac...> > To: 'Daniel A. Steffen' <st...@ic...> > Cc: 'David Zolli' <kr...@kr...>, tc...@li... > Subject: RE: [MACTCL] png problem on buttons > > Daniel A. Steffen wrote: >> On 11/05/2006, at 5:43, Jeff Hobbs wrote: >>> Yes, this helps. These are different paths, and I can now narrow >>> down the >>> issue (it's in tkMacOSXDraw.c:TkPutImage, the image->obdata case). >> >> I suspect what is going wrong is the copying of the image into the >> open QD picture used for the bevel button decoration, potentially >> related to this comment in SetupBevelButton: >> /* >> * TO DO - There is one case where XCopyPlane calls CopyDeepMask, >> * which does not get recorded in the picture. So the >> bitmap code >> * will fail in that case. >> */ >> >> it's possible tk's strategy of alpha-blending manually into the >> XGetImage of the bg may not work in this case anyway, as the native >> widget has probably not been drawn yet when the bg image is taken... > > Yes, I believe the latter is very much the issue. Any ideas? > > Jeff > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Tcl-mac mailing list > Tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > -- Michael Kirkham www.muonics.com |
From: Daniel A. S. <st...@ic...> - 2006-05-10 21:02:43
|
On 11/05/2006, at 6:49, Jeff Hobbs wrote: >> I suspect what is going wrong is the copying of the image into the >> open QD picture used for the bevel button decoration, hmm, it's actually more interesting, in Geoff's latest snippet if the button .c with the alpha-blended image is by itself, it works just fine (modulo issues below), as well as with the other button .d present, but if any of the labels .a or .b are present, the alpha- blended image doesn't display anymore... so probably some state, likely a graph port, that is not set/reset properly somewhere. >> it's possible tk's strategy of alpha-blending manually into the >> XGetImage of the bg may not work in this case anyway, as the native >> widget has probably not been drawn yet when the bg image is taken... > > Yes, I believe the latter is very much the issue. Any ideas? indeed, artifacts in the transparent pixels can be observed (if .c is by itself) in the example, due to this issue. We might have to bypass tk's blending here and pass the complex alpha data directly to the OS... Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** |
From: Daniel A. S. <st...@ic...> - 2006-05-10 22:26:50
|
On 11/05/2006, at 7:02, Daniel A. Steffen wrote: > hmm, it's actually more interesting, in Geoff's latest snippet if > the button .c with the alpha-blended image is by itself, it works > just fine (modulo issues below), as well as with the other > button .d present, but if any of the labels .a or .b are present, > the alpha-blended image doesn't display anymore... so probably some > state, likely a graph port, that is not set/reset properly somewhere. ok, I fixed the no-display issue, it was due to TkPutImage() not respecting the tkPictureIsOpen flag (same bits as in XCopyArea & XCopyPlane were necessary), c.f. patch below. This should also fix bug 1155596, please verify. > indeed, artifacts in the transparent pixels can be observed (if .c > is by itself) in the example, due to this issue. We might have to > bypass tk's blending here and pass the complex alpha data directly > to the OS... unfortunately support for placing images with arbitrary alpha on widgets was only brought in in Tiger with support for CGImage decorations, so this idea does not appear possible on earlier releases. On Tiger, we might be able to create a CGImage from the raw RGBA image data and use that instead of a QD picture as the button decoration. One possible (fairly expensive) solution for earlier releases might be to draw the undecorated widget into an offscreen buffer first and take the XGetImage bg from there; the trouble is that the XGetImage/ TkPutImage is all happening in the generic code, so there would need to be some changes there to add support for getting the background for blending from a different source than normal. Please feel free to have a go at this, it's not high on my list ATM... Cheers, Daniel -- ** Daniel A. Steffen Dept. of Mathematics ** ** Macquarie University NSW 2109 Australia ** --- tk8.5a4/macosx/tkMacOSXDraw.c 2006-04-11 20:20:33.000000000 +1000 +++ tk/macosx/tkMacOSXDraw.c 2006-05-11 08:06:12.000000000 +1000 @@ -272,16 +272,12 @@ XCopyPlane( srcPort = TkMacOSXGetDrawablePort(src); dstPort = TkMacOSXGetDrawablePort(dst); - if (tmpRgn == NULL) { - tmpRgn = NewRgn(); - } display->request++; GetGWorld(&saveWorld, &saveDevice); SetGWorld(dstPort, NULL); TkMacOSXSetUpClippingRgn(dst); - srcBit = GetPortBitMapForCopyBits(srcPort); dstBit = GetPortBitMapForCopyBits(dstPort); SetRect(&srcRect, (short) (srcDraw->xOff + src_x), @@ -395,12 +391,9 @@ TkPutImage( int i, j; BitMap bitmap; char *newData = NULL; - Rect destRect, srcRect; + Rect destRect, srcRect, *destPtr, *srcPtr; destPort = TkMacOSXGetDrawablePort(d); - SetRect(&destRect, dstDraw->xOff + dest_x, dstDraw->yOff + dest_y, - dstDraw->xOff + dest_x + width, dstDraw->yOff + dest_y + height); - SetRect(&srcRect, src_x, src_y, src_x + width, src_y + height); display->request++; GetGWorld(&saveWorld, &saveDevice); @@ -408,12 +401,32 @@ TkPutImage( TkMacOSXSetUpClippingRgn(d); + srcPtr = &srcRect; + SetRect(srcPtr, src_x, src_y, src_x + width, src_y + height); + if (tkPictureIsOpen) { + /* + * When rendering into a picture, after a call to "OpenCPicture" + * the clipping is seriously WRONG and also INCONSISTENT with the + * clipping for single plane bitmaps. + * To circumvent this problem, we clip to the whole window + */ + + Rect clpRect; + GetPortBounds(destPort,&clpRect); + ClipRect(&clpRect); + destPtr = srcPtr; + } else { + destPtr = &destRect; + SetRect(destPtr, dstDraw->xOff + dest_x, dstDraw->yOff + dest_y, + dstDraw->xOff + dest_x + width, dstDraw->yOff + dest_y + height); + } + if (image->obdata) { /* Image from XGetImage, copy from containing GWorld directly */ GWorldPtr srcPort = TkMacOSXGetDrawablePort((Drawable)image- >obdata); CopyBits(GetPortBitMapForCopyBits(srcPort), GetPortBitMapForCopyBits(destPort), - &srcRect, &destRect, srcCopy, NULL); + srcPtr, destPtr, srcCopy, NULL); } else if (image->depth == 1) { /* * This code assumes a pixel depth of 1 @@ -448,7 +468,7 @@ TkPutImage( bitmap.rowBytes = image->bytes_per_line; } destBits = GetPortBitMapForCopyBits(destPort); - CopyBits(&bitmap, destBits, &srcRect, &destRect, srcCopy, NULL); + CopyBits(&bitmap, destBits, srcPtr, destPtr, srcCopy, NULL); } else { /* * Color image @@ -479,7 +499,7 @@ TkPutImage( pixmap.rowBytes = image->bytes_per_line | 0x8000; CopyBits((BitMap *) &pixmap, GetPortBitMapForCopyBits (destPort), - &srcRect, &destRect, srcCopy, NULL); + srcPtr, destPtr, srcCopy, NULL); } if (newData != NULL) { |
From: Jeff H. <je...@ac...> - 2006-05-10 22:30:14
|
Daniel A. Steffen wrote: > On 11/05/2006, at 6:49, Jeff Hobbs wrote: >=20 > >> I suspect what is going wrong is the copying of the image into the=20 > >> open QD picture used for the bevel button decoration, >=20 > hmm, it's actually more interesting, in Geoff's latest snippet if the = > button .c with the alpha-blended image is by itself, it works just =20 > fine (modulo issues below), as well as with the other button .d =20 > present, but if any of the labels .a or .b are present, the alpha-=20 > blended image doesn't display anymore... so probably some state, =20 > likely a graph port, that is not set/reset properly somewhere. FWIW, I went through the exercise of ensuring that every SetPort and = SetGWorld had a Get/(re)Set surrounding it, and that made no difference for this. > indeed, artifacts in the transparent pixels can be observed (if .c is = > by itself) in the example, due to this issue. We might have to bypass = > tk's blending here and pass the complex alpha data directly to the = OS... There is also the larger issue that we should be getting away from QD = and/or removing all double-buffering tricks for OS X, as it already = double-buffers. Jeff |