Tkinter and "jumpiness"

[Douglas Alan]

Is it possible to double-buffer frame rendering with Tkinter? I'm
writing a GUI app using Tkinter and the GUI police around here are
complaining about the interface being too "jumpy" at times. If I
could have the frame rendered offscreen and only put onto the screen
once it has completely finished being rendered, then this would solve
the problem.

One culprit in the jumpiness is a megawidget that I am using that
initially displays a scrollbar and then a fraction of a second later
removes the scrollbar when it realizes that it is not necessary.

To eliminate the jumpiness, I've tried packing all the widgets into
the frame before packing the frame into the app, but that doesn't help
much. I've noticed, however, that if I pack the frame into the app,
unpack the frame (with the forget() method), and then repack it into
the app, on the repacking, the frame does not get get rendered in a
"jumpy" fashion -- even if the frame is being rendered into a
differently-sized area. This suggest that a lot of work is done on
the first packing that gets cached somewhere so that it doesn't have
to be redone on the repacking. Perhaps then an alternative to double
buffering the frame, if that is impossible, would be if I could
somehow get the frame to do all of that work that it currently does on
the first pack *before* the first pack, so the first pack would
display in the manner that subsequent packs do now.

|>oug

 

[klappnase]

Is it possible to double-buffer frame rendering with Tkinter? I'm
writing a GUI app using Tkinter and the GUI police around here are
complaining about the interface being too "jumpy" at times. If I
could have the frame rendered offscreen and only put onto the screen
once it has completely finished being rendered, then this would solve
the problem.

Have you tried useing wait_visibility() on the frame like this:

frame .wait_visibility(last_widget_that_is_created)
frame.pack()

I *think* from what you are writing this should solve your problem (if
I
understand you correctly).

One culprit in the jumpiness is a megawidget that I am using that
initially displays a scrollbar and then a fraction of a second later
removes the scrollbar when it realizes that it is not necessary.
(...)
|>oug

I had a similar problem with a widget with automatic scrollbars I
wrote; the fix
that worked for me was not to pack() the scrollbar within the
mega-widget's
__init__ method; I did the packing/unpacking from within the widget's
xscrollcommand that looks like this:

def _hscroll(self, *args):
self.hbar.set(*args)
if self.hbar.get() == (0.0, 1.0):
self.hbar.grid_forget()
else:
self.hbar.grid(row=1, column=0, columnspan=2, sticky='ew')

Within the widget's __init__ I just callled self.hbar.set(0.0, 1.0)
and could avoid the initial showing up of the scrollbar.


I hope this helps

Michael

 

[Douglas Alan]

Have you tried useing wait_visibility() on the frame like this:

frame .wait_visibility(last_widget_that_is_created)
frame.pack()

Hmmmm, I'm not sure that I see how this should work. As I understand
wait_visibility(), it should wait until last_widget_that_is_created is
displayed on the screen. But if the frame isn't yet packed, then
neither last_widget_that_is_created nor the frame will *ever* appear
on the screen, because wait_visibility() will forever wait for
something that won't happen until the waiting has finished.

I tried implementing your suggestion just to make sure that my
understanding is correct, and it behaved just as I expected -- i.e.,
it didn't work. Is there some other more subtle usage of
wait_visibility() that you have in mind?

I had a similar problem with a widget with automatic scrollbars I
wrote; the fix that worked for me was not to pack() the scrollbar
within the mega-widget's __init__ method;

That's a good idea -- thanks. I'd prefer not to modify the
megawidget, if possible, though. It's third-party software, and then
I'll have to worry about backporting my changes into it whenever I get
new distributions. Also, the megawidget is not the only source of
jumpiness, so it only fixes part of the problem. Since my original
post, I've heard rumors that one can indeed get a Tkinter frame to
double-buffer, but I haven't quite been pointed at the how to
accomplish that. If that doesn't pan out, perhaps I'll have to resort
to tweaking the megawidget, as you suggest.

|>oug

 

[klappnase]

I tried implementing your suggestion just to make sure that my
understanding is correct, and it behaved just as I expected -- i.e.,
it didn't work. Is there some other more subtle usage of
wait_visibility() that you have in mind?

Oops.......not really, I guess I've been tired.
Another idea:
have you tried the "primitive" way:

frame=Frame(master)
<..create other widgets...>
master.after(200, frame.pack)

or even:

root=Tk()
root.withdraw()
frame=Frame(root)
<..create other widgets...>
frame.pack()
root.deiconify()

That's a good idea -- thanks. I'd prefer not to modify the
megawidget, if possible, though. It's third-party software, and then
I'll have to worry about backporting my changes into it whenever I get
new distributions. Also, the megawidget is not the only source of
jumpiness, so it only fixes part of the problem. Since my original
post, I've heard rumors that one can indeed get a Tkinter frame to
double-buffer, but I haven't quite been pointed at the how to
accomplish that. If that doesn't pan out, perhaps I'll have to resort
to tweaking the megawidget, as you suggest.

Just another thought: if the megawidget's scrollbars don't work
properly
maybe it's possible to disable them at initialization and add your own
automatic scrollbars?

|>oug

Michael