Re: [ jEdit-devel ] Text drawing speedup

[Michael H <cm...@gm...>]

And it also would be useful (read speed increase to nearly eliminate size
issue) to limit the 'layout' to immediately viewable text. That is, compose
each paragraph, then test if the screen is full, and stop. Rather than
compose the whole document every time the display changes.

On Mon, May 25, 2020 at 11:29 AM Michael H <cm...@gm...> wrote:

> It would be nice if the "Full Layout" 'feature' could be selected. It's
> great to have at times, but if it could be disabled (like word wrap on the
> status bar) it would make jedit infinitely more useful. Most edits in plain
> text editors of 10mb files aren't composing the text, but are looking at
> code, and most of the code is restricted to unaccented, non-ligature,
> noncomplex text. The relatively few cases where someone wants to copyedit,
> having a toggle on the status bar ....
>
>
>
> On Mon, May 25, 2020 at 11:20 AM Matthieu Casanova <cho...@gm...>
> wrote:
>
>> In fact it's in the doc,
>>
>> Returns a new GlyphVector object, performing full layout of the text if
>> possible. Full layout is required for complex text, such as Arabic or
>> Hindi. Support for different scripts depends on the font and implementation.
>>
>> It's not a bug but a feature.
>>
>> --
>>   Matthieu Casanova
>>   cho...@gm...
>>
>>
>>
>> Lun 25 mai 2020, à 09:23, Matthieu Casanova a écrit :
>>
>> Hi,
>> I tested with Java 11 to java 15 and all of them have the same problem, I
>> am 99% sure it is in C++ native code, I am trying to understand what’s
>> wrong.
>> Maybe they are doing glyph of all part of the char array in order to get
>> a context or something like that ? But it would be strange.
>> I could try some Arabic and see if doing glyph of the middle of a word is
>> different if I give the entire char array of the word or only the letters I
>> want.
>>
>> Matthieu
>>
>> Le 24 mai 2020 à 20:11, Jesse Pavel <jp...@al...> a écrit :
>>
>> 
>> Hi Matthieu,
>>
>> Both Hotspot builds and OpenJ9 builds use the Harfbuzz shaping engine, I
>> believe, and the native shape() method of SunLayoutEngine seems to pass the
>> heavy lifting to Harfbuzz.
>>
>> Did you happen to test the code with Java 13 or 14? The bug reports for
>> slow glyph performance and poor LineBreakMeasurer performance have Java 13
>> listed as a fix version, though the details of the fix don't appear on the
>> Java Bug Tracker.
>>
>> Speaking of which, non-JDK contributors can use
>>
>>   http://bugreport.java.com/
>>
>> to report bugs, though they don't appear in the public bug tracker until
>> after an internal triage process (or so I gather from the mailing list).
>>
>> Jesse
>>
>> On Sat, May 23, 2020 at 6:29 PM Matthieu Casanova <cho...@gm...>
>> wrote:
>>
>>
>> Hey,
>> in fact I did not find the bug on the OpenJDK bugtracker, maybe it is a
>> new bug :
>> I quickly saw that the markTokens() method was the problem, in the
>> beginning I thought we were invalidating the lines too often or something
>> like that and I tried to optimize it.
>> But then I found it was strange that a big file was so slow against a
>> smaller file.
>> So I took a 10MB log file and duplicated the text until I had 100MB file.
>> And when going to any line of the file, the 100 MB file was much slower
>> than the 10MB file to display exactly the same thing.
>> Debugging markTokens showed me that marking one line could take 10ms in
>> one file and 100ms for the bigger file even if it is the same text.
>> Then I figured how to use visualvm to monitor CPU and saw that the slow
>> method when scrolling what the shape() method of SunLayoutEngine.
>> The method is c++ and what seems strange is that Hotspot and OpenJ9 have
>> the same problem but I don't think it is the same code isn't it ?
>>
>> To be sure I used JMH :
>>
>> import org.openjdk.jmh.annotations.*;
>> import sun.font.GlyphLayout;
>> import sun.font.StandardGlyphVector;
>>
>> import javax.swing.*;
>> import java.awt.*;
>> import java.awt.font.FontRenderContext;
>> import java.io.IOException;
>>
>> import static java.util.concurrent.TimeUnit.*SECONDS*;
>>
>> @State(Scope.*Benchmark*)
>> @Warmup(iterations = 2, time = 5, timeUnit = *SECONDS*)
>> @Fork(value = 0, warmups = 2)
>> public class GlyphBench
>> {
>>        public static final char[] *smallText *= new char[100000];
>>        public static final char[] *doubleText *= new char[1000000];
>>        public static final FontRenderContext *FRC *= new FontRenderContext(null, true, true);
>>        public  Font font;
>>        private int flags;
>>        private GlyphLayout gl;
>>
>>        @Setup(Level.*Trial*)
>>        public void setUp() throws IOException
>>        {
>>               font = new JLabel().getFont();
>>               flags = Font.
>> *LAYOUT_LEFT_TO_RIGHT*                     | Font.
>> *LAYOUT_NO_START_CONTEXT*                     | Font.*LAYOUT_NO_LIMIT_CONTEXT*;
>>               gl = GlyphLayout.*get*(null);
>>        }
>>
>>        @Benchmark
>>        @Measurement(iterations = 3, time = 10, timeUnit = *SECONDS*)
>>        public void smallText()
>>        {
>>               StandardGlyphVector gv = gl.layout(font, *FRC*, *smallText*,
>>                      0, 3, flags, null);
>>        }
>>
>>        @Benchmark
>>        @Measurement(iterations = 3, time = 10, timeUnit = *SECONDS*)
>>        public void doubleText()
>>        {
>>               StandardGlyphVector gv = gl.layout(font, *FRC*, *doubleText*,
>>                      0, 3, flags, null);
>>        }
>> }
>>
>>
>> The small text is 100000 and big text is 1000000, but I want glyph of 3
>> chars only.
>> And the result are
>>
>> GlyphBench.doubleText  thrpt    3   1225,655 ±   47,771  ops/s
>> GlyphBench.smallText     thrpt    3  27119,560 ± 1101,963  ops/s
>>
>> With a text that is 10 time bigger the big text is almost 20 time slower
>> to compute.
>> About posting bugs to OpenJDK, only contributors can do that ?
>>
>> --
>>   Matthieu Casanova
>>   cho...@gm...
>>
>>
>>
>> Sam 23 mai 2020, à 21:05, Jesse Pavel a écrit :
>>
>> Great catch, Matthieu!
>>
>> Can you please post a link to where you saw the JDK bug?
>>
>> I've been following bugs like
>>
>>   https://bugs.openjdk.java.net/browse/JDK-8214573
>>   https://bugs.openjdk.java.net/browse/JDK-8202131
>>
>> but I was wondering how you figured out it was the length of the char
>> array.
>>
>> Thanks,
>> Jesse
>>
>>
>> On Sat, May 23, 2020 at 3:38 AM Matthieu Casanova <cho...@gm...>
>> wrote:
>>
>>
>> Hey,
>> since 2 months I was searching the reason why jEdit was so slow with
>> medium and big files. In my memories it was fast  years ago.
>> First I looked at every changes in jEdit's code since years but found
>> yesterday that the bug is in the JDK :
>> an internal method used to create glyphs :
>>
>> sun.font.SunLayoutEngine.shape()
>>
>> When drawing glyphs we were giving a big char array of the size of the
>> buffer with start and stop offset of the interesting part of the text.
>> The problem is that the shape() method performances is proportionnal to
>> the length of the char array, not to the offsets.
>>
>> So I now copy only the few necessary chars to a new array and it is fast
>> again.
>> From what I saw this problem came with Java 11 and do not appear with
>> Java 8. I did not check Java 9 and 10.
>>
>> Please pay attention to the textarea display in any case, if you see
>> display problems, please let me know.
>>
>> --
>>   Matthieu Casanova
>>   cho...@gm...
>>
>>
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>>
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>