JDK-8034233 : Performance problem when editing in a JTextArea with bidirectional characters
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7u40
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2014-02-04
  • Updated: 2014-04-02
  • Resolved: 2014-02-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
1.7.0_40

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
If you look at the Java source for:

javax.swing.text.View.forwardUpdate(ElementChange, DocumentEvent, Shape, ViewFactory)

at some point it contains a line like:

        index0 = Math.max(index0, 0);
        index1 = Math.max((getViewCount() - 1), 0);
        for (int i = index0; i <= index1; i++) {
   ............................................

The extra line:

        index1 = Math.max((getViewCount() - 1), 0);

was added in one of the Java 1.7 minor bug fix releases and what it does is that when a character is pressed, the event to layout gets forwarded to all line views, inducing a very large performance problem when the document has bidirectional characters in it.

REGRESSION.  Last worked in version 7u10

ADDITIONAL REGRESSION INFORMATION: 
1.7.0_40

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a JTextArea with about 500 lines containing bidirectional characters. Edit in it.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
None but to overwrite problem method in custom view.


Comments
Closing this as Not an Issue for now. Please reopen or create new one, if the problem still reproducible on 7u60 or later.
14-02-2014

The following line: index1 = Math.max((getViewCount() - 1), 0); in View.forwardUpdate() method was added by the fix for JDK-8014863 (integrated in 7u40). However these changes caused some problems and were reworked under JDK-8024395 (integrated in 7u60-b01 and 8-b110). At the moment the method View.forwardUpdate() works as before, (i.e. changes made under JDK-8014863 were removed). According to JDK-8024395 the method forwardUpdate() was overridden for LogicalView class. LogicalView.forwardUpdate() sends update event to all views followed by the changed place. This event will cause view to drop the cache and re-calculate its break points. The fix does not cause the break spots re-calculation every time when a view is laid out. It initiates the break spots re-calculation only when an update of a document takes place. This is expected behaviour. So I recommend to re-test the problem on 7u60-b01 or 8-b110.
14-02-2014

assigned to the author of the fix for #8024395
12-02-2014

The JDK-8024395 fix was pushed to 8b110 and backported to 7u60b01.
12-02-2014

This is a regression after the JDK-8024395 fix, which completely replaced old code with new one. We must optimize new code.
12-02-2014

- please evaluate - what is the earliest affected release?
12-02-2014