<Swing Dev> [8] Review request for 8014863 Line break calculations in Java 7 are incorrect.

[dmitry markov]

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/view_bug.do?bug_id=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.
>>
>>
>