Bug 26265

Created attachment 32843 [details]
The mentioned screenshot.

It occurs when using ibus as well, so I imagine it's a Qt4 or KDE bug.

Furthermore, Anthy input into Kate 4.4rc* using either UIM or ibus is broken (for me). See https://bugs.kde.org/show_bug.cgi?id=222620 - and feel free to comment and confirm/deny.

The state of IMEs in the upcoming KDE SC 4.4 seems a bit flakey.

Created attachment 33470 [details]
Callgraph from uim with debug symbols

have now installed debug symbols of uim (should've done this before), and this gives us a better callgraph of what's happening.
this is from a simple qt application that just shows a text field, and I repeatedly typed ime-letters, slow and delayed as usual.

it would be great if an uim developer could at least look at the callgraph and tell me if the time spent in the various functions are sensible
for example, is it not unusual that for twenty seconds of activity some of these uim methods are called almost 400 thousand times?

Created attachment 33472 [details]
New screenshot from kcachegrind

New screenshot from kcachegrind, showing better what's happening

Could you tell me what version of qt4 exactly you use?  Perhaps something is changed in the filter event handling in the recent version of qt4... as I don't see any such problem with qt-4.5.3-9.fc12 (on Fedora).   Anyway I'll debug with latest qt4 later in my free time.

I'm using Qt 4.6.1. This bug is rather recent, I actually think it was not there in qt 4.5, but appeared once I upgraded to 4.6.

(In reply to comment #6)
> I'm using Qt 4.6.1. This bug is rather recent, I actually think it was not
> there in qt 4.5, but appeared once I upgraded to 4.6.
> 

I've just tried Qt 4.6.2, and confirmed the problem.  Even with XIM, its slowness existed.  It seems that event handling in drawing preedit of Qt 4.6.x is somewhat broken.  This should be solved in Qt itself.

(In reply to comment #7)
> (In reply to comment #6)
> > I'm using Qt 4.6.1. This bug is rather recent, I actually think it was not
> > there in qt 4.5, but appeared once I upgraded to 4.6.
> > 
> 
> I've just tried Qt 4.6.2, and confirmed the problem.  Even with XIM, its
> slowness existed.  It seems that event handling in drawing preedit of Qt 4.6.x
> is somewhat broken.  This should be solved in Qt itself.
> 

Thanks for confirming this bug. I am very interested in getting it fixed, so would you mind describing the bug more in detail so that I can submit it to qt bugtrackers?

(In reply to comment #8)
> Thanks for confirming this bug. I am very interested in getting it fixed, so
> would you mind describing the bug more in detail so that I can submit it to qt
> bugtrackers?

It seems Qt 4.6.x doen't draw and update preedit string synchronously even the event sent from the input method has already handled internally.  Since committing text from input method doesn't show such delays, event handling just for drawing preedit text seems culprit.  Perhaps this problem only appears on X11 platform but I'm not sure.

(In reply to comment #9)
> It seems Qt 4.6.x doen't draw and update preedit string synchronously even the
> event sent from the input method has already handled internally.  Since
> committing text from input method doesn't show such delays, event handling just
> for drawing preedit text seems culprit.  Perhaps this problem only appears on
> X11 platform but I'm not sure.


I've just noticed the delay of displaying preedit text seem only existed on QLineEdit widget.  Inputting text on QTextEdit *does* work fine even with Qt 4.6.2.

(In reply to comment #10)
> I've just noticed the delay of displaying preedit text seem only existed on
> QLineEdit widget.  Inputting text on QTextEdit *does* work fine even with Qt
> 4.6.2.

For the bug in qlineedit, a patch for Qt 4.6.2 pasted below should fix the problem.  It is a bug in QLineControl::updateDisplayText() which doesn't check the existence of preedit text when updating the area. 


--- qt-kde-qt-mac/src/gui/widgets/qlinecontrol.cpp.orig 2010-02-17 12:18:04.0000
00000 +0900
+++ qt-kde-qt-mac/src/gui/widgets/qlinecontrol.cpp      2010-03-06 23:05:48.0000
00000 +0900
@@ -102,7 +102,7 @@
     m_textLayout.endLayout();
     m_ascent = qRound(l.ascent());

-    if (str != orig)
+    if (str != orig || !preeditAreaText().isEmpty())
         emit displayTextChanged(str);
 }

Apologies if this comes through as unrelated, but could this also explain the bug at https://bugs.kde.org/show_bug.cgi?id=222620? Both were introduced at roughly the same time, and if this patch to Qt4 fixes them both then that's happy news.

(In reply to comment #11)

Maybe this should be better.  It also update the line when deleting preedit text.

--- qt-kde-qt-mac/src/gui/widgets/qlinecontrol.cpp.orig	2010-02-17 12:18:04.000000000 +0900
+++ qt-kde-qt-mac/src/gui/widgets/qlinecontrol.cpp	2010-03-06 23:35:54.000000000 +0900
@@ -406,8 +406,9 @@
 void QLineControl::processInputMethodEvent(QInputMethodEvent *event)
 {
     int priorState = 0;
+    QString oldPreeditText = preeditAreaText();
     bool isGettingInput = !event->commitString().isEmpty()
-            || event->preeditString() != preeditAreaText()
+            || event->preeditString() != oldPreeditText
             || event->replacementLength() > 0;
     bool cursorPositionChanged = false;
 
@@ -477,6 +478,8 @@
     }
     m_textLayout.setAdditionalFormats(formats);
     updateDisplayText();
+    if (preeditAreaText() != oldPreeditText)
+        emit displayTextChanged(preeditAreaText());
     if (cursorPositionChanged)
         emitCursorPositionChanged();
     if (isGettingInput)

(In reply to comment #12)
> Apologies if this comes through as unrelated, but could this also explain the
> bug at https://bugs.kde.org/show_bug.cgi?id=222620? Both were introduced at
> roughly the same time, and if this patch to Qt4 fixes them both then that's
> happy news.
> 

I'm not sure as I haven't setup KDE yet.  But I guess KWrite uses its own input method handling perhaps.

(In reply to comment #14)
> (In reply to comment #12)
> > Apologies if this comes through as unrelated, but could this also explain the
> > bug at https://bugs.kde.org/show_bug.cgi?id=222620? Both were introduced at
> > roughly the same time, and if this patch to Qt4 fixes them both then that's
> > happy news.
> > 
> 
> I'm not sure as I haven't setup KDE yet.  But I guess KWrite uses its own input
> method handling perhaps.

For the kwrite problem, changes in kdelibs-4.4.0/kdelibs-4.4.0/kate/view/kateviewinternal.cpp seems to be culprit.

I think following patch is the right way to check what it should be.  As far as I tested, it fixes the problem with uim.


--- kateviewinternal.cpp.orig   2009-12-31 22:29:14.000000000 +0900
+++ kateviewinternal.cpp        2010-03-07 15:36:48.073367864 +0900
@@ -3778,7 +3778,7 @@

   // if the input method event is text that should be inserted, call KateDocument::typeChars() with
   // the text. that method will handle the input and take care of overwrite mode, etc.
-  if ( e->commitString().length() > 0 && doc()->typeChars( m_view, e->commitString() ) ) {
+  if ( e->commitString().length() > 0 && !m_imPreeditRange && doc()->typeChars( m_view, e->commitString() ) ) {
     e->accept();
     return;
   }

But I'm not sure what the original code is intended, so please consult KDE developer about this.

Etsushi, thanks a lot for your efforts. I have posted your patch and bug description to the Qt bugtracker, and have linked it to this bug for more information. It is found here:

http://bugreports.qt.nokia.com/browse/QTBUG-8807