Tk Source Code

View Ticket
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: ef9c3730e38d240eb4dd8dd806279ab0ae652729
Title: Black window during resize in py2app tkinter
Type: Bug Version: 8.6.9
Submitter: radarhere Created on: 2018-12-18 23:26:05
Subsystem: 66. Aqua Window Operations Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2021-01-26 02:49:55
Resolution: None Closed By: radarhere
    Closed on: 2021-01-26 02:49:55
Hi. I understand that this isn't the place for tkinter or py2app bugs, but I presume that this is related to the macOS 10.14 tk/tcl changes in 8.6.9, and hopefully is suitably straightforward to reproduce. Thanks very much for your work. 

On macOS 10.14, with tk/tcl 8.6.9, when running Tkinter in Python 3.7.1 from the following, the Tkinter window appears correctly and works fine when resizing. 

When building an application using py2app 0.18 and the following, the Tkinter window still appears correctly when stationary. However, during resizing of the window, it becomes black.

import tkinter 
root = tkinter.Tk() 

from setuptools import setup 
User Comments: radarhere added on 2021-01-26 02:49:55:
This is no longer an issue

kevin_walzer added on 2019-08-23 11:53:04:
This issue is not present in IDLE 3.7.1 linked against the current tip of core-8-6-branch.

The release of ActiveTcl that you have does not reflect extensive work that has been done to reconfigure Tk's drawing engine to changes in macOS introduced in Mojave, and which will be deployed in 8.6.10, coming soon. 

The use of py2app should not have any bearing on bugs in Tk; I have found that py2app does not play nicely with Tk in general and have moved away from using it in my Python app in favor of a roll-your own-solution. 

Can you bundle your app against the current tip of core-8-6-branch and report back? Otherwise I'm inclined to close this as "works for me."

anonymous (claiming to be mastersoft) added on 2019-08-23 02:40:40:
The behavior observed with tkinter can be reproduced using ActiveTcl 8.6.9 (, the current release), with Mac OSX 10.14.6 (Mojave), in the following ways: 

Scenario 1: Use the mouse to resize any toplevel in Wish, including the console.
Scenario 2: Option-click on the green button in the Mac OSX title bar to toggle the window to/from full size.

In either scenario the toplevel window body remains black throughout the resizing action, and is restored after completion. This did not occur in earlier versions of Tcl.

In ad hoc test cases for further diagnosis, Tk events were recorded in a script during resizing scenarios, down to microsecond resolution using [clock microseconds]. Logs of these events showed that a lower level fault is likely.

Logs of test runs included all events that were expected, but in an unexpected sequence. Specifically, a series of paired <Configure> and <Expose> events occurred as expected in the toplevel and child windows; these events had expected screen coordinates and were separated by expected time increments of 3 – 20 milliseconds. But unexpectedly, this series of <Configure> and <Expose> events occurred _before_ the <ButtonPress> event that would presumably trigger a drag action for resizing. A similar out-of-order sequencing relative to a <ButtonPress> event also occurred for the Option/click event that would trigger auto-resizing. 

In addition, the <ButtonPress> event, apparently after-the-fact, was followed by a sequence of <Configure> events in the toplevel only. The properties of these <Configure> events mapped to the properties of the <Configure> events that occurred before the <ButtonPress> event, but these latter events were separated by time increments of only 20 microseconds or less – too brief to be sequenced with screen refreshes in real time. After the end-of-resizing <ButtonRelease> event, one more <Expose> event occurred, this one presumably to finally refresh the toplevel display from a black window to its original contents.

Notably, no <Expose> events occurred between <ButtonPress> and <ButtonRelease> event pairs. Perhaps this is what kept the toplevel black. It’s as if the <ButtonPress> event stalled proper event sequencing until the <ButtonRelease> event occurred, but out-of-order handling occurred after the stall.

marc_culler (claiming to be Marc Culler) added on 2018-12-19 04:29:30:
I recall seeing this behavior at one point during the Mojave adventure.  But
my apps built with Tk 8.6.9, Python 3.7.1 and py2app 0.18 do not do this.
So I am pretty sure that if you rebuild Tk using the latest core-8-6-branch
source and rebuild python3.7.1, taking care that it actually links against
your newly build Tk 8.6.9 (see
then this problem will go away.