[8] Review request for 8014863 Line break calculations in Java 7 are incorrect. (original) (raw)

dmitry markov dmitry.markov at oracle.com
Mon May 27 14:09:30 UTC 2013

Hi Alexander,

I have changed the fix according to your comments: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014863 webrev: http://cr.openjdk.java.net/~vkarnauk/8014863/webrev.01/

The method View.forwardUpdate() will send 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.

Also I added some wrapper methods to the test. These methods are intended for accessing JEditorPane from the EDT thread.

Could you review the changes, please?

Thanks, Dmitry

On 24/05/2013 15:35, Alexander Scherbatiy wrote:

On 5/24/2013 11:46 AM, dmitry markov wrote:

Hello,

Could toy review the fix: bug: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=8014863 webrev: http://cr.openjdk.java.net/~vkarnauk/8014863/webrev.00/ The fix removes break points caching from GlyphView. If some text is inserted/removed into/from the document contained several elements, all elements views will re-calculate their break points. For example the ParagraphView.calculateMinorAxisRequirements method can invoke several methods like getBreakWeight() and calculateMinorAxisRequirements() that both leads to GlyphView.getBreakSpot() method invocation on the same method when the text is not changed. So the breakSpots cache is still useful in this case. May be there are some missed places during text updating where the breakSpots cache should be cleaned. The getNumberOfTextLines() method in the test uses the JEditorPane on the main thread. There is the invokeOnEDT() method in test Util class that helps to return a result from the EDT thread. Thanks, Alexandr.

Thanks, Dmitry.

More information about the swing-dev mailing list