[Bug swing/24152] major performance problem in JTextArea (TextModel?)

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #3 from hendrich at informatik dot uni-hamburg dot de  
2005-10-06 07:36 -------
Hello Tony,

> I recently made 3 classpath commits that deal with this (it's not just
> one patch, which is why I haven't sent you a patch or attached a patch
> to the bug report), so if you have time, you could run the testcase on
> CVS HEAD and take a look.

thanks!

Repainting after resizing is a lot faster now, but still slower than 
I would like (still several seconds on large texts sometimes. However, 
there are some irregularities in the "feel" and the timings, which might
be related to my windowmanager (ctwm) instead of JTextArea).

Regarding the repainting, I think that we cannot make any real progress
unless the JScrollPane issues are finally fixed. JTextAreas are almost
always embedded in JScrollPanes, and the repainting performance will 
critically depend on JScrollPane and JViewport reporting the correct
view position and viewport clip rectangle.



> [your message to classpath-patches]
>
> However, the method getDemoText (in the test case attached to the bug
> report) still runs orders of magnitude slower on classpath than on the
> JDK.  The calls in the method are to Math.random and to
> StringBuffer.append.  Someone may want to look into this.

I did look at it. Adding an extra timing check shows that getDemoText() 
with Math.random() and StringBuffer is fine; naturally jamvm is a little
slower than Hotspot, but the performance is pretty good.

The time is spent in JTextArea.setText(). I tried running in gdb and
getting backtraces. A typical one looks somewhat familiar, like this:

#0  0x401249c9 in _int_malloc () from /lib/libc.so.6
#1  0x40123898 in malloc () from /lib/libc.so.6
#2  0x47319e22 in IA__g_malloc (n_bytes=1075709472) at gmem.c:137
#3  0x472a6f96 in fribidi_analyse_string (str=0x86ff7b8, len=67,
    pbase_dir=0xbe1ff4dc, ptype_rl_list=0x41000001, pmax_level=0x41000001 "")
    at fribidi.c:527
#4  0x472a7a40 in pango_log2vis_get_embedding_levels (str=0x86ff7b8,
    len=1075709472, pbase_dir=0x41000001,
    embedding_level_list=0x86ff8d0
"|\006\036@|address@hidden|address@hidden") at fribidi.c:1034
#5  0x472951fe in itemize_state_init (state=0xbe1ff56c, context=0x41000001,
    text=0x0, base_dir=PANGO_DIRECTION_LTR, start_index=4259, length=67,
    attrs=0x86efef0, cached_iter=0x86c87f8, desc=0x0) at pango-context.c:664
#6  0x47295ed7 in pango_itemize_with_base_dir (context=0x401e0620,
    base_dir=PANGO_DIRECTION_LTR,
    text=0xbe1ff56c "(\003>\b\200$p\bf5p\b#5p\b°ã6G", start_index=0,
    length=1090519041, attrs=0x86efef0, cached_iter=0x86c87f8)
    at pango-context.c:1183
#7  0x4729d208 in pango_layout_check_lines (layout=0x86f04d0)
    at pango-layout.c:3211
#8  0x4729b715 in pango_layout_get_extents_internal (layout=0x86f04d0,
    ink_rect=0x0, logical_rect=0xbe1ff798, line_extents=0x0)
    at pango-layout.c:2005
---Type <return> to continue, or q <return> to quit---
#9  0x4729ba58 in pango_layout_get_extents (layout=0x41000001, ink_rect=0x0,




Also, I got the following during one of the PR24512 runs (when I moved the 
window while the resize loop was running):

java.lang.NullPointerException
   at java.lang.String.<init> (String.java:515)
   at java.lang.String.<init> (String.java:241)
   at gnu.java.awt.peer.gtk.GdkFontMetrics.charsWidth (GdkFontMetrics.java:110)
   at javax.swing.text.PlainView.insertOrRemoveUpdate (PlainView.java:352)
   at javax.swing.text.PlainView.insertUpdate (PlainView.java:376)


- Norman


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24152