This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | QuietEditorPane is repainted few times after typing one character into the Java file | ||
---|---|---|---|
Product: | java | Reporter: | Marian Mirilovic <mmirilovic> |
Component: | Editor | Assignee: | Max Sauer <msauer> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues, msauer |
Priority: | P2 | Keywords: | PERFORMANCE, T9Y |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Marian Mirilovic
2007-01-10 16:42:53 UTC
I guess the extra repaint comes after reparse of the java file that comes after 500ms see JavaSource.REPARSE_DELAY and that may create semantic higlightings. Is that possible to run the test on a plain text file to verify this idea? Thanks. We are running tests also on a plain text file, so stay tuned I'll look there. Mila I have a question about the semantic higlightings: From this test seems the code in this file has already been highlighted - I wrote only one character and the way it changed the source code - the semantic highlighting is not changed. So question is : do you repaint the semantic highlighting even if there is no change? Currently, the semantic highlighting always repaints whole editor after each parse. Rewrite of it (to repaint only what is necessary to repaint and to improve some other things) is planned after the new highlighting API is merged. We will definitely have to have a look at it. > I guess the extra repaint comes after reparse of the java file that comes after
> 500ms see JavaSource.REPARSE_DELAY and that may create semantic higlightings.
> Is that possible to run the test on a plain text file to verify this idea?
Verified, if I run the same test case in Plain text editor the measured values
are close to 10ms , so I think Mila is right.
I'll add "Type a character in Plain editor" into our test suite.
Anyway thanks for clarification.
Reassigning since this is now mainly about optimizations in java related things. I was investigating the effect of fix for issue #87642 on repaints, and it looks quite good (for more details on the method below): -for the case denoted here, no (delayed) repaint on behalf of the Java editor should be done (unless there is a compilation error nearby the caret position, but this is not the case as I understand it) -while in some cases the editor is repainted as a whole (on behalf of the Java editor), these cases should not be very common -generally, the span and number of repaints (on behalf of the Java editor) is reduced So, I think this issue can be closed - the original problem is fixed. Marian, is it possible to verify on the testing machines? The method of testing: -I used javax.swing.DebugGraphics to visualize the repaints -I have modified QuietEditorPane by adding the following at the end of the constructor: setDebugGraphicsOptions(DebugGraphics.FLASH_OPTION | DebugGraphics.LOG_OPTION); DebugGraphics.setFlashCount(1); DebugGraphics.setFlashTime(20); RepaintManager.currentManager(this).setDoubleBufferingEnabled(false); -org.netbeans.editor.FontMetricsCache expects to get Graphics2D, but DG is not G2D, so FMC needs to be adjusted. I have simply commented out the cast, and assigned (strikethrough|underline)Offset = 0 and (strikethrough|underline)Thickness = 1. -I have disabled caret blinking to eliminate repaints from the caret -I have changed the reparse delay org.netbeans.api.java.source.JavaSource.REPARSE_DELAY to 3000 (3 seconds) to clearly separate the repaints before and after parse. Type a character in Java Editor Linux Sol Win 1st usage 49 34 21 Subsequent usage 7 11 6 NB Full Dev[200708151200] JDK 1.6.0_02 Looks like regression happened. Build 200708271200: Type a character in Java Editor [1] 22 ms 100 ms Type a character in Java Editor [2] 7 ms 100 ms Build 200708281200: Type a character in Java Editor [1] 550 ms 100 ms Type a character in Java Editor [2] 568 ms 100 ms Build 200708291200: Type a character in Java Editor [1] 539 ms 100 ms Type a character in Java Editor [2] 544 ms 100 ms I think I know where the problem is: fix of issue #109886 causes that JPanel in: new javax.swing.JPanel(); is colored using two different attributes collections - one for class and one for constructor. Please note that this may not be visible in all color schemes, as the two attributes collections may be painted using the same color. The problem is that only one of these collections "wins" after each reparse, and so the word "JPanel" may be repainted after each reparse (each time the attributes collection for the given word changes). Unfortunately, I did not have time to actually go through the code and try to find out why this happens and how to fix it. So, I propose to rollback the fix of issue #109886, reopen it, and deal with it later. I've prepared a fix for this. I've made my own measurements of 'Type a character in Java Editor': - 578/542/557/571 before the fix - 43/6/8/6 after the fix --- Checking in SemanticHighlighter.java; /cvs/java/editor/src/org/netbeans/modules/java/editor/semantic/SemanticHighlighter.java,v <-- SemanticHighlighter.java new revision: 1.22; previous revision: 1.21 done verified in 200709060000 |