#1677 Slow processing irregular transparencies

If you have a photo image with irregular transparent
patches dotted around it it takes an atrociously long
time to copy. It seems to be exponentially related to
image size. For instance, here it takes about 2.5
minutes of CPU time on my Athlon XP1600 to create this
fairly compact 750x500 image by tiling a small but
holey initial image (attached)...

% info patchlevel
8.4.2
% image create photo p1 -file flip_v.gif
p1
% image create photo p2
p2
% p2 copy p1 -to 0 0 750 500
< 150 second pause occurs here>
%

[Anonymous]

.gif with transparent bits throughout

[Donal K. Fellows]

Logged In: YES
user_id=79902

Duplicated. Yuck. Probably (i.e. I've not looked yet, but
it's where I think it'll be wrong) a fault in valid region
management....

[Donal K. Fellows]

Logged In: YES
user_id=79902

Confirmed that the region code is *desperately* inefficient
as used by the photo code. :^( The problem is the way that
Tk_UnionRectWithRegion() allocates and disposes with a
temporary region. (See tkWinRegion.c for the gory details.)

[Donal K. Fellows]

Logged In: YES
user_id=79902

Perhaps it is better to use a thread-local or interp-local
region and SetRectRgn() instead?

http://msdn.microsoft.com/library/en-us/gdi/regions_8nqm.asp

[Donal K. Fellows]

Logged In: YES
user_id=79902

I think I've fixed this in 8.5 (or at least reduced the
number of regions that Tk on Win allocates and destroys as
part of processing such an image!)

Can someone check this out, and if it really is fixed, let
me know so I can backport it?

[Anonymous]

Logged In: YES
user_id=456242

A quick, unscientific test seems to indicate performance in
this respect is little changed between 8.4.9 and 8.5a2 --
sorry to say
--Jasper

[Donal K. Fellows]

Logged In: YES
user_id=79902

There was a separate performance problem too. Can you
recheck with 8.5a4 or 8.4.13? (I have site-specific build
problems.)

[Donal K. Fellows]

Logged In: YES
user_id=79902

Bleah, still broken with 8.5a4rc2 even under Linux. :-(

% time {p2 copy p1 -to 0 0 750 500}
80670358 microseconds per iteration

The cost appears to be the region handling (or at least it's
deep in the guts of XShrinkRegion where I'm most likely to
interrupt inside a debugger, which serves as a very crude
kind of profiling). Fixing this is going to require enough
work that it isn't going to happen in time for 8.5a4

[Donal K. Fellows]

Logged In: YES
user_id=79902

A couple of other minor notes to save myself time when I
next come back to this:

The culprit is one (extremely long-lasting) call to
TkpBuildRegionFromAlphaData, and that already only processes
the part of the image being updated. There aren't multiple
calls to Tk_PhotoPutBlock to optimize out. :-(

The local-compositing scheme used with complex alpha is
probably the way to go, though that's got its own set of
performance troubles and has problems with partial image
drawing...

[Donal K. Fellows]

Modern hardware speeds this up. 28 seconds on OSX... 8-(