Hello Dmitry
Looks good !
Thanks
alexp
On 5/27/2013 6:09 PM, dmitry markov wrote:
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.
