| Ticket UUID: | fde9dc2392607c97f92d43cd952adcef238a27a0 | |||
| Title: | X error BadDrawable when using ttk::style element create with multiple displays | |||
| Type: | Bug | Version: | bug-c23f79ef96 branch, 8.6.18, 9.0.5, 9.1b1 | |
| Submitter: | sbron | Created on: | 2023-12-05 19:46:28 | |
| Subsystem: | 88. Themed Tk | Assigned To: | nobody | |
| Priority: | 5 Medium | Severity: | Severe | |
| Status: | Closed | Last Modified: | 2026-10-26 11:43:03 | |
| Resolution: | Fixed | Closed By: | nemethi | |
| Closed on: | 2026-10-26 11:43:03 | |||
| Description: |
When using a ttk widget that uses an image element on a different display than the display of ., the application terminates with an X error: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 62 (X_CopyArea) Resource id in failed request: 0x20000d Serial number of failed request: 757 Current serial number in output stream: 759This happens because the ttk image elements are created using Tk_MainWindow(interp) as the associated widget. The images are then used indiscriminately for all subsequent widgets, including widgets on a different display. As the images don't actually exist for that display, X_CopyArea throws the error mentioned above. This error only shows up with the fix for [c23f79ef96], because without that the application already crashes before getting to this point. | |||
| User Comments: |
nemethi (claiming to be Csaba Nemethi) added on 2026-10-26 11:43:03:
Serhiy, many thanks for your alternative fix, which is now merged into main, core-9-0-branch, and core-8-6-branch by commits [85428671], [07e021e2], and [5ace0365]. Schelte, Christian, and Christopher, can you please confirm that this solution works for you as expected? serhiy.storchaka added on 2026-09-28 14:22:35: Still reproducible with 8.6, 9.0 and 9.1 (also with Xft). The fix in branch bug-fde9dc2392 was never merged. Proposed alternative fix in branch ttk-image-multiple-displays, with tests image-3.1 and image-3.2 (need TK_ALT_DISPLAY). Unlike bug-fde9dc2392, it does not add new functions to tkImage.c and does not create a new image instance on every drawing: the images are got once for every other display, for a window on that display, and released when that window is destroyed. Nothing changes for a single display. chrstphrchvz added on 2023-12-10 15:08:14: The TkImageForWindow()/TkImageEqual() approach seems non-ideal to me (e.g. possibly increased maintenance burden), but I have no alternative ready to offer. My guess is Ttk should instead be storing just the name of the image or some other intermediate thing, rather than retrieving and storing a Tk_Image token too early. fvogel added on 2023-12-10 12:33:37: Testcase added, see [d7784f6081]. fvogel added on 2023-12-09 17:44:26: Christian's patch committed [6de380f3|here] by Schelte. sbron added on 2023-12-05 20:07:44: After this problem was mentioned on the tcl-core mailing list (https://sourceforge.net/p/tcl/mailman/message/58347839/), Christian Werner came up with a proof of concept fix in his AndroWish repo: https://www.androwish.org/home/info/ccc996aeffde47f8 I have applied his changes on top of the bug-c23f79ef96 branch. First results look promising. | |||
Attachments:
- bug-fde9dc2392.tcl [download] added by sbron on 2023-12-05 19:48:50. [details]