Got to the bottom of redraw slowness.

[Phil Norman]

Hi.

I've been suffering for a long time with Evergreen being rather slow at redrawing under certain conditions. I've finally figured out two root causes.

The particular condition under which the speed really sucks is if there are lots of spelling mistakes on the screen, and 'find' is active and there are several highlighted matches on the screen. Under such conditions, simply typing causes horrible slowness.

This is down to two things.

Thing one: when 'find in files' is active, every keypress triggers all the find matches to be dropped and recalculated. This essentially causes the entire editor pane to be redrawn. So that's a complete redraw for every keypress - bad. Particularly on a 4k monitor with one file vertically maximised.

Thing two: the redraw speed for those little wiggly lines absolutely sucks. It's implemented by a long series of 2.84-pixel-long lines, with anti-aliasing enabled.

I've so far tackled thing 2: by pre-generating a BufferedImage with 100 pixels of wiggly line, redraw speed improves by a huge amount. Redrawing a screen-full of spelling mistakes on my BSD machine took 0.07s instead of 4.5s; the speed-up when I tried it on a laptop was a factor of 370.

However, it may be worth tackling thing 1 as well. It seems crazy to force a complete repaint of everything for every keypress. My suggestion would be, instead of clearing the highlights and then recalculating them, to calculate the new highlights, then compare them against the existing ones, only replacing those that have changed.

Cheers,

Phil

[Martin Dorey]

> when 'find in files' is active

Should that be just Find?

Any value in our usual solution of deferring the work until there's been no further demand for it to be redone for 0.5s?

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/evergreen-users/CAOa8eG4uaCryJiDStXcjyT0d_fYy%3DtRMd_WnxWNG7Riy_%3Dcz%2Bg%40mail.gmail.com.

[Phil Norman]

Hi.

Yes, sorry, just plain 'Find'.

Deferring the work would actually work well, yes. However, deferring the work *and* diffing the highlights and only redrawing what's changed would be even better :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/evergreen-users/CABZkMPv8Tb%2BThz69FOSTEFjxLv%2BF1yUwe%3DXy%3DANc%3DKQjp3o5qg%40mail.gmail.com.

[Phil Norman]

I finally got around to diffing the highlights. The deferral did indeed help a lot, but I've still found myself explicitly cancelling finds I don't need because having one active makes editing slow. The change I just pushed still does a full regexp match across the file (which is another, less important possible optimisation), but it only adds/removes highlights that need to be. So under most typing conditions, typing results in no change in the find highlights, so the only thing redrawing is the text being changed/moved about.

Seems to work well as far as I've tested. Please scream if I've broken something.

Maybe someday we should add some unit testing to this thing. Hard to do so late in the day, mind.

Cheers,

Phil