Tk Source Code

Ticket Change Details
Login
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

  1. 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].
    
  2. login: "marc_culler"
  3. mimetype: "text/plain"
  4. username: "Marc Culler"