|No such thing as a small change|
Thanks BrowserUk for your very detailed explanations.
I'm amazed that we're facing this problem at all: if, for example, I obscure the Firefox window into which I'm currently typing, then reveal it again, it redisplays exactly as you would expect; I am sure that the Firefox code doesn't have to contain things like sub-second checking loops just to redisplay the contents of its own window. Surely the task of redrawing a window when it is revealed is down to the window manager, not the application whose window it is? So why is Perl/Tk any different? Is this a "feature" of Tk, or is it something that has gone wrong in the Perl interface to it? You say this in the nature of GUIs - but this is so crazy that I find that difficult to believe, with all respect to you.
I'm also surprised that this problem, which must surely be one that many many people will have faced, doesn't appear to have a standard workaround, let alone a fix.
Regarding the choices you list, I agree that (1) is not nice. I am very uncomfortable with (2), on the basis that making the machine do a lot of work just to wait for something to happen simply doesn't seem a sensible way to approach anything. I think your (3) is the only realistic option. I can't visualise in detail how this would be done, but I guess it could use Proc::Background as suggested by Anonymous Monk below. (However the 2 responses to that suggestion both involve the same kind of crazy loops as your choice (2)!)
I became diverted away from this problem, hence the very late response to you, and I now find I cannot devote any more time to it. I'll finish writing my application without trying to display a Perl/Tk window in parallel with another application's window, so this issue will no longer arise.
Many thanks to everyone who has contributed to this.