Tk Source Code

* Description:

The interaction between Tk and the ibus-daemon slows down the creation of simple widgets drastically. ibus-daemon cpu usage goes to 100% while widgets are created.

* System Information:

Ubuntu 20.04.3 LTS / GNOME Version 3.36.8 / Windowing System X11

* How to reproduce:

Run the script try_ibus.tcl on a fresh install of Ubuntu (see below)

The script will create 480 text label widgets in a simple rectangular layout. The widget creation is extremely slow. On my machine (AMD FX-8350) it takes approximately 
1.5 s  until all widgets are created. Note that the run time of the script will even grow if the script is called repeatedly, eventually it reaches 5 seconds. While the
script is running the cpu usage of ibus-daemon rises to 100% (can be checked by running the top command from the command line). If ibus-daemon is killed before running
the test script run time decreases to 50 ms.

* Conclusion:

The interaction of Tk and ibus-daemon causes a drastic slow-down of widget creation. Any moderately complex application written in Tcl/Tk will appear very sluggish and
kind of unprofessional. Since Ubuntu is a popular distribution for the linux operation system, I consider this bug important.

* Note

It seems that the problem was already discussed (https://core.tcl-lang.org/tk/info/340006f5d055809b) under the topic "X11 is very slow to create widgets".
The ticket was created on 2019-11-22, and some patches were presented. However the discussion thread ended on 2021-06-09, without including the patch in
the most current Tcl/Tk8.7a5. I would very much appreciate it if a bug-fix could enter mainline Tcl/Tk soon. Many thanks in advance! 

* Edit (22-02-24)

I reported the bug already 4 months ago, but it seems that nobody has taken care. If you consider the bug as unimportant or you are lacking resources to look at it, please feel free to delete this bug report. Many thanks.

-----------------------------------------------------------------------------------------------------

#
# try_ibus.tcl
#
# a simple script that measures the time needed to create 480
# text labels arranged in a 40 x 12 grid 
#
#

set tcl_version [ info tclversion ]
set tk_version  [ package require Tk ]

set MAIN(status)  "tcl $tcl_version/ tk $tk_version: Running test, please wait ..."
set MAIN(t0)      [ clock milliseconds ]

set f0 [ frame .f1 ]
set l1 [ label $f0.l1 -textvariable MAIN(status) ]

pack $l1 -side left -padx 3 -pady 3 
pack $f0 -side top -fill x


set f0 [ frame .f2 ]
set f ""
set l ""
for { set i 0 } { $i < 12 } { incr i } {

	set f [ frame $f0.f$i -bg blue ]
	
	for { set j 0 } { $j < 40 } { incr j } {
	
		set l [ label $f.e$j -text "." ]
		pack $l -side left -fill both -expand true
		
	}
	pack $f -side top -fill x -expand true
}
pack $f0 -side top -fill both -expand true

bind $l <Expose> cb 


proc cb { } {
	
	global MAIN
	
	set t1 [ clock milliseconds ]
	set dt [ expr 0.001 *( $t1 - $MAIN(t0)) ]
	set MAIN(status) [ format "Test completed, run time: %.3f s" $dt ]
}

Jan merged branch x11-lazy-xic to [e978f0d457|main] and [7345531fbe|core-9-0-branch]. Backported to [0003874f7a|core-8-6-branch].

Still reproducible with 9.1b1. With ibus running as XIM server, creating 480 labels takes 342-475 ms and 480 entries 390-491 ms, against 36 ms and 15 ms without an input method. Under mutter 50.1 with Xwayland, which is the desktop of this report, the numbers are the same: 394-459 ms and 380-381 ms.

The cause is the one Brad Lanam found in 2019: Tk_HandleEvent() creates an X input context for every window as soon as it gets any event, and each creation costs a round trip to the input method. Branch x11-lazy-xic creates it only for a toplevel and for the window which receives the focus, following the approach of the abandoned bug-xim branch. The same measurements then give 20-29 ms and 6-7 ms under xfwm4, and 40-51 ms and 13-14 ms under mutter, which is what the application costs without an input method at all.

Not included: the bug-xim branch also deferred OpenIM(), which would avoid the XIM connection entirely for applications which never focus a text widget.

My opinion is that whe have to get approval from dkf on the patch before merging. The several comments he posted about the proposed patch [in the other (duplicate) ticket] show he has concerns. I also remember a chat discussion one year ago from which I gathered the same feeling.

Basically: dkf knows this area much better than I do, and I don't feel confident in merging this patch unless he approves.

@François,
Hi,
in your opinion, as mkl211031 tests are ok, as my tests are ok, what could be next steps?

best regards,
nicolas

Compiled the branch I got from nab (https://core.tcl-lang.org/tk/info
/1de11ec53b3dcb14) on my Linux machine (AMD FX-8350 / Ubuntu 20.04.3 LTS/
GNOME Version 3.36.8). ibus-daemon is present.

Test script now runs without visible delay (total run time: 100 - 200 ms).

Also did some simple tests switching the input method while typing text into
an entry widget (German, Simplified Chinese: intelligent pinyin), finally killed
ibus-daemon when entry widget was still active.

Works all flawlessly. Many thanks!

here's the branch:
https://core.tcl-lang.org/tk/info/1de11ec53b3dcb14

++

Many thanks for the explanation and for the good work!

I would be willing to do some testing with the xim patch, 
but so far I've been unable to find the code repository 
("bug-xim branch"). Unfortunately I'm not very familiar
with git and the like, so any advice would be welcome.

on the raspberryPi running raspberryPiOS (64bits) where I am using Tk8.7 (trunk) compiled thanks to llvm+clang aarch64 toolchain I've installed ibus:
sudo apt-get install ibus

I've run @mkl211031 script several times (x20) and the worst score I got was 0.412s
but it does not increase, I usually got 0.149s and the worst were 0.412s

so maybe that's one more step in favour of Tk8.7...

++

on macOS with Tk (from the bug-xim branch) linked against X11, everything in my app works as expected.
but there's no ibus-daemon involved

++

Nicolas,

The patch is in branch bug-xim. This is off core-8-6-branch, but I have put it up-to-date. Thanks for your upcoming tests and reports.

Besides, I really think we should have someone proficinet in the input methods area to confirm the implementation.

Hi François,
if you could initiate a branch offset of of trunk I can test with my app on raspberryPi, virtual Linux and Tk linked against XQuartz on macOS

++

About your "Edit (22-02-24)": I understand your frustration. That said, we lack someone with sufficient time and knowledge to address this. I and others have spent quite considerable time on this (in [340006f5d055809b]). The slowdown is an important issue, but we have to be 100% sure the patch will not break input methods before applying it. I have requested for a second opinion, but nobody stepping in so far. We just lack resources, but I don't think we should delete unsolved tickets for such a reason.