I am beginning to get an inkling of what this ticket is about.

First, there are two calls to XCopyArea in tkImgPhInstance.c, one of which
never arises for macOS.  The other call is in TkImgPhotoInstanceSetSize.  It
is called to copy the part of the old image which is also inside of the
new resized image.  So XCopyArea is being used to copy from a pixmap to a
pixmap.

That case of XCopyArea was not really ever implemented in 8.0, as evidenced
by the cryptic comment:
XXXX Need to deal with pixmaps!

The 9.0 XCopyArea does do something in that case, but it is very roundabout.
(I believe it hardly ever matters because in 99% of the applications the
size change is 1x1 -> widthxheight and only happens the first time the
image is drawn.)

I have another theory, which you sort of hinted at.  That theory is that
you are writing your own image type and you are basing your code on
tkPhImgPhInstance.c.  So you copied the Resize function, which contains
the call to XCopyArea, and you are measuring the time for that call
in your own image implementation.

I also suspect that your code is only calling XCopyArea in the case where
the image is being resized from 1x1 to wxh, so the call to XCopyArea is
only changing 1 pixel, and even if it is not actually doing anything at all
in 8.6 it still would not cause any trouble for your code.

Here is my plan.  I am going to fix XCopyArea so it handles the pixmap to
pixmap case efficiently, and not worry about the pixmap to window and window
to pixmap cases for now.  After I do that, I predict that your timing issues
will be gone.  Then I can worry about the other two cases, (or leave them
in their current inefficiant state until someone actually uses them. :^} )