The only real 'inefficiency' in your code is flipping on a half second
flip. But I very much doubt the speed of the exchange is the issue.
The speed with which the screen can be repainted, and whether the
repaint is synchronized with the display scan rate, is what is very
likely causing the flicker. I.e., the flicker is part of the old
display visible for one refresh period because the old bitmap was still
present in the frame buffer when that part of the screen was redrawn.
The classical way that games (and other apps that need such) avoid such
an issue is double buffering. The display is refreshed from one bitmap
while a second bitmap is drawn into. Then in sync with the screen
refresh the entire bitmaps are exchanged (actually the address the
video card begins reading the screen data from is swapped, but same
effect). So the old image is visible, then the new image appears, in
one single refresh interval.
Tk does not expose any ability out to Tcl to do synched updating,
although maybe a C extension could be written to do so. Nor does it
expose out any direct ability to do double buffering, so there is
likely no way to fully eliminate the flicker without writing some low
level C extensions.
> The small delay here is only meant to quickly illustrate the issue.
> In my actual application, this swapping occurs at much lesser rate,
> but the flickering is still noticeable to keen eyes. Oh well.
Very likely because it is just an inherent property of how modern video
screens are repainted.
>> Other angles to try (although I suspect the same end result may occur
>> for all but the last, because invisible windows are 'unmapped' and
>> making them visible means 'mapping' them, which means redrawing their
>> contents):
>>
>> 1) Use the placer (or grid with two or more widgets in the same grid
>> cell) and then use raise/lower to make a specific frame visible.
>
> Tried and failed.
>
>>
>> 2) Use the canvas, without scroll bars attached, then move the view
>> port around via script calls on the canvas to make a specific frame
>> visible.
>
> This is gonna be a huge rework with manual paint and custom widget
> behaviors. And then, it's not even guaranteed to work.
Testing with your big button example would be less work than reworking
your code first. Yes, still likely to exhibit the flicker, but much
less effort than refactoring your code without knowing if it will help
or not.
>> 3) Rethink your implimentation to work out a way to not need to do
>> this 'swapping' (i.e., open new toplevel child windows instead).
>> But this may be your least preferred suggestion.
>
> I guess this is the best outcome. I'll think more about a new UX.
Or, of course, the forth option: just live with the tiny bit of
flicker.