FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]
And, supposingly, any other OS.

A DESCRIPTION OF THE PROBLEM :
GlyphView.java:719
            breakPoint = breaker.next(s.offset + s.count - 2);
                                  ^--HERE
      Should be:
            breakPoint = breaker.following(s.offset + s.count - 2);

    BreakIterator.next(int) expects its argument to reflect the number of times
    to invoke the next() routine. What was intended here is following(), which
    expects an offset. This makes a major bottleneck for applications, which use
    GlyphView-based text components (e.g. JEditorPane, JTextPane) with large
    models of multibyte text, since each call to getBreakWeight() or breakView()
    for GlyphView, responsible for an element in paragraph with start offset of,
    say, 100000 and end offset of 100200, will result in 100000 of useless
    iterations.

    This only applies to multibyte (i.e. non-English) text input . I have discovered
    this when profiling my text client application, trying to figure out, why
    does it get significally slower as more text is input. I have fixed this in my
    private implementation of GlyphView and tried it - everything works just fine.
    Hope it gets fixed until 1.5 final.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a JTextPane, wrapped by JScrollPane, and input there a large amount of text, say 1000000 characters. See how much time it takes to input one character.


REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2005-04-11 11:42:37 GMT