Overview
Artifact ID: | 9c7f1e097090ce01d8fbb60ee7d55b5e2d2ca64b672ab550ef55dfa4e1a6fdb4 |
---|---|
Ticket: | 4af5ca1921122de63f37a99beefb2f5dbef72518
XCopyArea is very (very) slow on macOS with version 9 |
User & Date: | marc_culler 2025-07-26 21:34:42 |
Changes
- icomment:
Thank you Christopher. I was actually quite worried about that. However, the changes I made in XCopyArea only affect the case where both source and destination are pixmaps. It seemed to me that, in that case, scaling could not possibly be an issue so one could simply extract the source rectangle from the src drawable as a CGImage and then draw that CGImage into the context of the dst drawable. Do you agree? Of course there are still some weird things. For example, if you take a screenshot of a rectangle on a Retina display and then display the resulting png image in a Tk label, the dimensions of the label image will be twice as large as the dimentions of the rectangle used for the screenshot. Apple treats each 0.5x0.5 subpixel as a pixel when it generates the png file. But I don't think that Tk can do anything about that. It has no knowledge of the source of a .png file, and must display 1 png pixel as a square with sides of length 1 Apple point on an Apple screen, whether or not an Apple point corresponds to the width of a screen pixel or to twice the width of a screen pixel for that particular screen. I will try to check that this change does not cause a regression of [685ac30727].
- login: "marc_culler"
- mimetype: "text/plain"
- username: "Marc Culler"