Menu
▾
▴
tcl-bugs
|
From: <no...@tc...> - 2024-08-04 18:48:19
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [08859bd4603807e5f105fd95c1ae2fbf9f8a722894bbae746004469404d110e7] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-04T18:43:39.165 Details https://core.tcl-lang.org/tk/tinfo?name=08859bd4603807e5f105fd95c1ae2fbf9f8a722894bbae746004469404d110e7 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields comment: The Img extension uses XGetImage for format option "-window" to get a "screenshot" of a widget. This fails using Tk 9.0.b3 on Mac. Previous versions (8.6, 8.7, 9.0.b2) worked fine. It also works fine using Tk9.0.b3 on Windows or Linux. The call of XGetImage returns NULL, because the CGImageRef returned by function CreateCGImageFromDrawableRect only has 3 samples per pixel, but is checked for having 4. This new behaviour seems to be related to changes at the beginning of function CreateCGImageFromDrawableRect, where a CGContextRef is created. Attached test script derived from the Img test suite demonstrates the error. icomment: Hi Paul, Can you please say which are the recent changes to CreateCGImageFromDrawableRect that you think are involved? I am not seeing any changes newer than 2022. I would be suspicious of the call to: [view.layer renderInContext:cg_context]; which I think only makes sense when drawRect is being used. But that was added in 2021. I would think that with the new updateLayer code the image should be copied from the CGImage backing layer. However, that layer may not have an alpha channel since it is used as the contents of an opaque window. Under what conditions would you expect XGetImage to return an image with alpha values < 1? login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-04 21:48:13
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [b48bf73eb2648aa29fc1e993d1b79b9e753155ee56b8f5556e564bd7f10adec6] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-04T21:42:25.567 Details https://core.tcl-lang.org/tk/tinfo?name=b48bf73eb2648aa29fc1e993d1b79b9e753155ee56b8f5556e564bd7f10adec6 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: CreateCGImageFromDrawableRect has definitely changed with the change to using updateLayer. I guess I don't know how to make fossil show me changes for a file in a specific branch. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-04 22:33:12
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [51ae99845a5c7fbc049aac660f73ad9539c767c2473aa908973fc5f78b262257] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-04T22:28:11.131 Details https://core.tcl-lang.org/tk/tinfo?name=51ae99845a5c7fbc049aac660f73ad9539c767c2473aa908973fc5f78b262257 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: I can confirm that CreateCGImageFromDrawableRect is returning an image with 3 bytes per pixel. Possibly the issue is that the NSContentView backing CALayer is being created without an alpha channel. Alternatively, we could just handle images of that format by setting alpha to 1.0. That would mean that we can't use the current simple approach of directly copying the image data from the CGImage to the XImage with memcpy. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-05 02:03:16
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [01628fd0cac724c2387ff7c082f1c616a8315400b7fe58a7627ca75c198e719e] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-05T01:50:06.001 Details https://core.tcl-lang.org/tk/tinfo?name=01628fd0cac724c2387ff7c082f1c616a8315400b7fe58a7627ca75c198e719e Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: The old code, using drawRect, could not really implement XGetImage. Instead it would redraw the entire widget (or toplevel) using a new bitmap context. It was not a copy of what had already been drawn. Now all rendering is done to a CGImage which is the backing layer for the contentView of the window. So XGetImage only needs to copy a subrectangle of that image into a new image. The code involving the scaling factor is there to prevent the screenshor from being twice the size of the widget in the case where the computer has a retina display -- an old bug. Evidently the current backing layer does not have an alpha channel. I am not sure whether that should change. (It would allow transparent windows, I believe.) Otherwise we can just not use any alpha channel, which is more or less what your patch to XImage was doing. (I will be a little surprised if the image looked correct, but I see that the code was using the reported value for bytes-per-row to configure the XImage and to allocate and copy the XImage data. So it might have actually worked correctly. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-05 03:18:17
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [8c91749c3a19f0a9cdd528fcf104ad5e7b43a912ee41a78f68618ecc769d745e] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-05T03:15:37.771 Details https://core.tcl-lang.org/tk/tinfo?name=8c91749c3a19f0a9cdd528fcf104ad5e7b43a912ee41a78f68618ecc769d745e Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: My esperiments indicate that even though the NSBitmapImageRep is reporting samples_per_pixel = 3, the image data in the CGImage that we get from CreateCGImageFromDrawableRect is using 4 bytes per pixel in the default ARGB32 format with the alpha byte set to 255. The code (unchanged from 8.6 as far as I know) that checks the image format wanted to see bytes_per_row == width * samples_per_pixel. But the data we are getting has bytes_per_row == width * 4 even though samples_per_pixel is reported as 3. I guess that is a way of saying that all alpha values are 255. But this is a change from what it was reporting when we were using drawRect. I have created a bugfix branch bug-b7d813f008 which removes that part of the test and appears to make your script work. Can you please test? Thank you. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-07 21:33:20
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [b261a971f3e7a7896a7ca7461fdad5779c7fa67cdfb39cf76b805db742ad9fd3] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-07T21:32:48.745 Details https://core.tcl-lang.org/tk/tinfo?name=b261a971f3e7a7896a7ca7461fdad5779c7fa67cdfb39cf76b805db742ad9fd3 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: As I said, prior to the CGImage drawing change, the XGetImage function was a hack. It did not copy anything from the screen. It had the window redraw itself to a new CGImage and then copied a rectangle from that. Since we were creating the CGImage used for drawing, we had complete control over its format. Now all drawing is done to a CGimage which functions as the backing store for the window, and XGetImage copies a rectangle from that image. That is much more like what the other platforms do. Indeed it is a mystery why the backing CGImage reports 3 samples per pixel yet requires 4 * width bytes per row to store the image. The fourth byte, where we expect the alpha value appears to be set to 255, since when we copy it from the CGImage data and use it as alpha we do not get a transparent image. I can only guess that thereported 3 samples per pixel is a signal that Apple uses to indicate that all alpha values are 255. Anyway, things are different because the images are being created in completely different ways. I am not sure how XGetImage is used in the tests, however, because the tkTest.c and tkMacOSXTest.c files define their own special image type. (I forget which file defines that test image type.) login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 14:18:23
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [604971859db1afda771bc8d8f4b9c973bd79ba2d72024955dd7e4c150c5e54b0] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T14:04:18.039 Details https://core.tcl-lang.org/tk/tinfo?name=604971859db1afda771bc8d8f4b9c973bd79ba2d72024955dd7e4c150c5e54b0 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields comment: The Img extension uses XGetImage for format option "-window" to get a "screenshot" of a widget. This fails using Tk 9.0.b3 on ac. Previous versions (8.6, 8.7, 9.0.b2) worked fine. It also works fine using Tk9.0.b3 on Windows or Linux. The call of XGetImage returns NULL, because the CGImageRef returned by function CreateCGImageFromDrawableRect only has 3 samples per pixel, but is checked for having 4. This new behaviour seems to be related to changes at the beginning of function CreateCGImageFromDrawableRect, where a CGContextRef is created. Attached test script derived from the Img test suite demonstrates the error. icomment: I don't see how the current design of Aqua Tk could possibly allow capturing the off-screen parts of a canvas. If you look at the code in tkCanvas.c you will see that the canvas widget draws the canvas to a private pixmap **unless** TK_NO_DOUBLE_BUFFERING is #defined. The Aqua port defines that compiler variable, and no other platform defines it. When that is defined, the canvas widget clips all drawing to the window frame and draws the visible parts directly to the screen. The off screen parts of the canvas are never drawn. There is no place to even look for an image containing those parts of the canvas. The TK_NO_DOUBLE_BUFFERING flag has existed from the beginning of the Aqua port of Tk, so this is not a new issue. It would be possible to rewrite the Aqua portions of the canvas widget code to draw the entire canvas to a private CGImage managed by the canvas and copy the visible portion of that CGImage to the screen in the DisplayCanvas function. It would also be possible to leave that code as is, but provide a separate means of asking a canvas to draw its entire content, including the off-screen part, to a CGImage. Either of those options would involve a major rewrite of tkCanvas.c, which seems to me to be out of the scope of this ticket. Note that the TK_NO_DOUBLE_BUFFERING flag is also used in the code for the Text widget, the other "scrollable" widget, in much the same way. If I were starting the huge project of rewriting the Aqua code for the Text and Canvas widgets I would probably look into using Apple's NSClipView, which is a native Objective C class that has a scrollable backing layer which can be larger than the window. Apple also provides the NSScrollView comprised of an NSClipView together with scrollbars that can be configured to automatically become hidden when the NSScrollView is large enough for the entire image to be visible. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 17:03:22
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [84a571f32e7667da14d101ae02999ec94c4071dc4f8f218832732a297c9b514f] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T17:01:58.268 Details https://core.tcl-lang.org/tk/tinfo?name=84a571f32e7667da14d101ae02999ec94c4071dc4f8f218832732a297c9b514f Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields comment: The Img extension uses XGetImage for format option "-window" to get a "screenshot" of a widget. This fails using Tk 9.0.b3 on ac. Previous versions (8.6, 8.7, 9.0.b2) worked fine. It also works fine using Tk9.0.b3 on Windows or Linux. The call of XGetImage returns NULL, because the CGImageRef returned by function CreateCGImageFromDOrawableRect only has 3 samples per pixel, but is checked for having 4. This new behaviour seems to be related to changes at the beginning of function CreateCGImageFromDrawableRect, where a CGContextRef is created. Attached test script derived from the Img test suite demonstrates the error. icomment: I am not sure whether the Img extension is expecting that XGetImage would somehow be expected to know what the entire Canvas scrollregion looks like, even though parts of it had never been drawn to the scteen. With the old implementation which would create a new CGImage and ask the canvas to redraw itself using a graphics context for that CGImage, it would be easier to imagine how to create an image of the entire Canvas. But I don't know how XGetImage would even be able to find the dimensions of the scrollregion, since I don't think it is supposed to have any knowledge of the inner workings of the window it is getting an image from. I think I am pretty far from understanding how the Img extension implements the -format window -data $canv options that you are using in your script. I will need an explanation. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 18:18:21
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [fbb73141acbe2b325abf186acc6784b8b4f3e3062198a0fd160d615b86115d4c] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T18:08:07.983 Details https://core.tcl-lang.org/tk/tinfo?name=fbb73141acbe2b325abf186acc6784b8b4f3e3062198a0fd160d615b86115d4c Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: OK. Now I am beginning to get the idea. Your Tcl code scrolls the canvas around attempting to move every part of the scrollregion into the visible part of the canvas, then take a screenshot using XGetImage, then assemble all of the screenshots into a single image. The individual screenshots are used as tiles. But the screenshot tiles are a little larger than the visible part of the window, so they include parts of the scrollbars around the edges. When the tiles are assembled into a single image, the image includes a grid pattern which is made up of pieces of scrollbars. I conclude that the problem which you are trying to report here is that the bounds being used by XGetImage are slightly larger than the visible rectangle of the canvas. The XGetImage function is passed x, y, width and height. The fact that your script works correctly on Windows is evidence that those values are correct. The macOS implementation of XGetImage calls: cgImage = CreateCGImageFromDrawableRect(drawable, 1, x, y, width, height); The second parameter is a flag called "force_1x_scale". Just as a wild guess, it looks like maybe we are somehow getting 0.99 scale instead of 1.0 scale. I will try looking at CreateCGImageFromDrawableRect and see if I can see anything suspicious. The thin grey lines suggest that the dimensions are off by 1, which could be related to the rounding that you are doing when you compute pr. The scrollbar images suggest that some more complicated image scaling is taking place. I note that dimensions of macOS windows, as well as pixel coordinates, are floating point. So there are other opportunities for rounding errors. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 18:18:21
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [31933ae172a1daeaa0319870eef3af2029816611bc4d81d5efcf265f15fb52ed] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T18:13:16.311 Details https://core.tcl-lang.org/tk/tinfo?name=31933ae172a1daeaa0319870eef3af2029816611bc4d81d5efcf265f15fb52ed Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Harald, I don't think we can document any limitations until we know what the limitations are, and until we know whether we are looking at a limitation or a bug. It is not at all clear to me at this point. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 19:18:21
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [d3b86fec974ecc790cdb5d85f2b62ee9c47a746fe53e7ce31cef1c02dfb14419] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T19:12:42.194 Details https://core.tcl-lang.org/tk/tinfo?name=d3b86fec974ecc790cdb5d85f2b62ee9c47a746fe53e7ce31cef1c02dfb14419 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Paul, you didn't mention what hardware you were using when you made those screenshots. It actually matters. I just uploaded a screenshot of your CaptureCanvas.tcl script taken on a mac mini running macOS 14 with a Dell monitor. You will see that it looks fine. You were probably using an Apple Retina screen when you made your screenshots. That implies that when you call CreateCGImageFromDrawableRect with the force_1x_scale flag set your image needs to be rescaled. (A pixel on a retina screen has size 0.5 points by 0.5 points, where that unit is an Apple point not a printer's point and represents the size of a "logical" pixel not the size of a hardware pixel on the actual monitor. So the bug you are reporting (I now think it is a bug) involves the code which does the rescaling in the case of a retina screen. One thing that means is that debugging will most likely require use of a retina screen. Harald, don't worry. I am able to resist that kind of pressure. I would not suggest releasing 9.0 until this is fixed. OF course I would welcome any debugging assistance that anyone felt like providing. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 20:18:21
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [2516a63e2029b00ad0e48ac288743bb941e87f52e607aa36c3b6f20fdb1980f0] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T20:06:28.073 Details https://core.tcl-lang.org/tk/tinfo?name=2516a63e2029b00ad0e48ac288743bb941e87f52e607aa36c3b6f20fdb1980f0 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: So you have a Retina screen, as I guessed. However, I now have a fix which makes your script work, and I think indicates that this bug is actually a bug in the grid manager and has nothing to do with XGetImage. I only thought to try this because I discovered it in my own project (which uses Python's tkinter module) after I ported tkinter to Tk 9.0. I don't know the exact nature of the grid manager bug. But I know a hack that works around it. What is happening with your script is that the grid manager has not stabilized the size of the small window with scrollbars, so that window has a different size on the screen than it reports with Tk_Width and Tk_Height. Here is the fix: Add one line as below: grid rowconfigure $w.par 0 -weight 1 grid columnconfigure $w.par 0 -weight 1 wm geometry . [wm geometry .]; #Add this line More details to follow ... login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 21:33:27
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [3dae565147207a121e2061b1e54400b94f801bd653d14d981015cb754e54fcaf] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T21:25:07.043 Details https://core.tcl-lang.org/tk/tinfo?name=3dae565147207a121e2061b1e54400b94f801bd653d14d981015cb754e54fcaf Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Hi Paul, I just attached a screenshot from my Intel Macbook Air with Retina screen and macOS 14. This includes the weird no-op geometry command. The screenshot looks correct to me. So now we are down to differences between Intel and M2. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 21:48:16
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [4c2078728a0a7dc0558180f430af9fc7703c80987936d774c9725619a1f45c8d] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T21:39:12.915 Details https://core.tcl-lang.org/tk/tinfo?name=4c2078728a0a7dc0558180f430af9fc7703c80987936d774c9725619a1f45c8d Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Sorry. It is not correct on the Intel either. Expanding the window made that more clear. (See expanded screenshot. But the problem is essentially the same - at the moment when XGetImage is being called (after the initial layout or after a scroll) the window has not alwsys been fully redisplayed with the correct layout and with the correct new scroll position. In my latest screenshot the top left tile is OK. The other tiles in the first row seem to come from the second row. The second and third rows are OK. So I still think the core issue is not with XGetImage, but with ensuring that the window has been fully updated before calling XGetImage. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-09 22:03:25
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [5b953dc9ab45f996169ada04291046822cf8c6b0b2033a80d489faa8060bd4aa] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-09T21:53:45.795 Details https://core.tcl-lang.org/tk/tinfo?name=5b953dc9ab45f996169ada04291046822cf8c6b0b2033a80d489faa8060bd4aa Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: I think the scrollbars are confusing the issue here as well. By adding calls to update after each scroll I get an image that looks correct except that it has scrollbars with overlapping thumbs along the right side and the bottom. In the other case where I was seeing issues with the grid manager the window size was off by exactly 10 pixels, which coincidentally is the width of the scrollbar. So I think the appearance of the merged scrollbars is really a reflection of an issue with the grid manager. And, of course, the grid manager works fine on the other platforms and does not have any platform-specific code. That is always how these adventures go. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-10 04:18:17
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [234d656e0216991edcba232b0e0921d85a4fe6ab9638bd2a325e2594964b80ff] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-10T04:04:36.375 Details https://core.tcl-lang.org/tk/tinfo?name=234d656e0216991edcba232b0e0921d85a4fe6ab9638bd2a325e2594964b80ff Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Hi Paul, I think I found the bug. It is in the section of code in CreateCGImageFromDrawable which rescales the image when using a retina display. It was simply using the entire window instead of clipping to the specified rectangle. In the case of your script that meant that each tile was a copy of the visible scrolled canvas with the scrollbars included, instead of just the visible part of the canvas. Each of those tiles would be rescaled to the correct size, so they fit together correctly but contained artifacts that look like scrollbars. The fix is in a new branch bug-b7d813f008-retina. Can you please test that? Thanks. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
|
From: <no...@tc...> - 2024-08-10 13:18:23
|
Automated mail by fx, on behalf of no...@tc... Ticket Change [7399cb04c1cc613786ac70b5879505dd43736244cdcd3a6530e47c36e9f88815] [XGetImage fails on Mac using Tk 9.0.b3] By marc_culler For Tk On 2024-08-10T13:16:32.196 Details https://core.tcl-lang.org/tk/tinfo?name=7399cb04c1cc613786ac70b5879505dd43736244cdcd3a6530e47c36e9f88815 Ticket https://core.tcl-lang.org/tk/tktview/b7d813f008173e9760fe13a07749dc3f513faf41 Changed Fields icomment: Prior to merging the cgimage_drawing branch there would have been no rescaling done (and no image capture either). Instead the Canvas widget would have been asked to redraw itself to a new graphics context which would then have been used to generate an image. The current scaling algorithm is provided by Apple and is used automatically when drawing an image to a rectangle in a CGImageBitmapContext, which is allowed to have a different size. I was hoping to use this to track down the issue with the grid manager. Too bad. login: marc_culler username: Marc Culler ------------------------------------------------------------ See Tcl/Tk development @ http://core.tcl-lang.org/ ------------------------------------------------------------ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X