Making a code editor, Part 3
Since my last blog post, I've fixed a lot of bugs and issues. Now I create/find slightly less bugs/issues then I fix! So the bug list has started to shrink. Actually the bug list currently only has seven items!
I did however find two bugs while writing this, which are now fixed ... *grin*
Code Editors are hot news
But like I wrote in earlier blog posts, whenever one of my "competitors" are mentioned, people will complain it's slow when editing huge files (two million lines or more).
Who the hell use such large files? Answer: Those who edit compiled assembly code.
Opening a huge file seems to be the universal benchmark for a code editor. So I've done some optimizations for that ... Thanks to "streams" you can now open up really huge files. I tried with a 10 GB log file and it loaded in like 10 milliseconds. You can not yet edit these file streams though. It's not on my priority list, but something I probably have to fix before release.
Measuring input latency
Last week I stumbled upon a tool that lets you measure text input latency. And a great article about the affects of input latency in text editors. In other words, how fast the text turns up on the screen after you push a key ...
This is how my editor (JZEdit) compares with Notepad++ on Windows 7:
I ran the test tool inside a HTML file (with syntax parsing/coloring) to make it a realistic test.
And this is how it looks with Window classic instead of the default Windows 7 theme:
The results are inconsistent though, sometimes it stays at 5ms, but almost always goes up to 16-20ms after a few seconds.
I've spent far too much time trying to figure out why. But I think this has to do with Chromium shell / nw.js syncing monitor refresh rate (VSYNC), while Notepad++ doesn't.
My conclusion is that if my editor can render within the VSYNC time-frame, which is around 16ms on 60Hz monitors, it will be fine.
Written by Johan Zetterberg Mars 22, 2016.