I think I saw something like this on the internet:
Tkinter uses double buffering to avoid flicker.
What does this mean and how and where?
Graphical application typically have these components:
When you make a Tkinter draw commands, you're not actually directly changing the screen. Instead, you're just modifying the scene graph. In Tkinter, the objects in the scene graphs are the Tk/Python objects that you're calling.
When your application calls the function to update the screen (or when you reenter the main loop) the scene graph are flushed. This means that the scene graph are interpreted, and the UI library calls the low level draw routines that updates the image in the back buffer.
At the end of the flushing phase, the front and back buffer are flipped. This means that the buffer that used to be used as a back buffer now becomes the front buffer, and a new back buffer is allocated (or more commonly, the old front buffer now becomes the new back buffer).
Concurrently with all that, the monitor will always read what to draw on the screen from the front buffer.
All these updating and flipping means that the front buffer never contains partially updated image, even if the update rate of the application and the update rate of the screen doesn't match, the frames are always perfectly drawn.
Without double buffering, what could happen is that the application will draw images directly into the same buffer that the monitor reads pixel data from. In a single buffer system, you can sometimes see screen flickering or tearing, which is when part of the screen displays images that comes from previous frame and the other part of the screen displays images from the next frame.
None of this is specific to Tkinter, but pretty much all graphic systems would have something similar in their rendering pipeline, though they vary in exact details and terminologies may vary. In graphical systems that uses GPU, the buffers may actually be in GPU memory instead of the main memory; some graphic frameworks may not have any scene graphs as they expect the application to design any logical description of the scene themselves (and keep track of dirty pixels); sometimes the front buffer may have post processing applied before being sent to the screen so it doesn't directly correspond to the actual images on screen; sometimes the front buffer may actually be composited by a windowing system into a bigger scene; etc, etc.