Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] "Typing with pleasure"

I've only now had time to read the whole thing, but, it's a very interesting article. I liked that it went into a lot of detail, including stuff like keyboard input lag and monitor latency - although those are more of an aside that normally only twitch gamers know and care about.

But the core of the article is about IDE latency, and I like the focus that it puts on making sure there is a smooth typing experience. This should be a design principle in the back of the mind of anyone who is working on a IDE. Personally I never felt any issue with typing in Eclipse, but I work on Windows (and actually with classic theme), which according to the benchmark actually has pretty good latency, so that matches with my experience. It only gets worse in Linux.

It could be interesting, especially on Linux, to run the benchmark tool on just an SWT Text snippet, just to see how much delay is just due to the SWT widgets (and possibly the Window Manager/Compositor), as opposed to delay incurred by Eclipse itself. Then again with all the issues Eclipse has been having on Linux and GTK3, it might be far from the list of important things to work on.

By the way, the importance of having a smooth UI typing experience is why, when I was writing the on-the-fly/asynchronous auto-save (https://git.eclipse.org/r/#/c/68546/), I had to make sure the UI performance would not be affected, that no significant UI delays would be introduced. That's why the patch is a bit complicated, as the save work which is normally done in UI thread, has to be offloaded to a background thread. And the standard buffer dirty state listeners can't be notified on that background thread, because they might expect to be run in the UI thread. But the notifications can't be posted to the UI thread either (with asyncExec for example), because there is no knowing how long they will take. And it would not be okay to be posting these events on nearly every keystroke.


On 23 April 2016 at 19:29, Cole Markham <cole@xxxxxxxxxxxxxxxx> wrote:

Based on the post I read on the IDEA zero-latency implementation, it seems it only applies to the first keypress. Further, the testing tool used for these results is specifically designed to measure the optimization that the zero-latency mode uses. The tool does support rapid keypress testing, but I don't think it was used for this article. I think it was skewed to make the zero-latency mode look like the winner, but that's just a hunch. In either case, independent results with more real world conditions would answer some of these questions.


On Sat, Apr 23, 2016, 10:39 AM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote:
On 2016-04-22 12:44 PM, Chris Aniszczyk wrote:
> Some interesting data around visual latency of editors, Eclipse being
> included:
> https://pavelfatin.com/typing-with-pleasure/#editor-benchmarks

This is probably a dumb question, but would it make sense to implement a
"zero latency" mode in the Eclipse editor? Or perhaps another question
would be: how prevalent is use of IDEA's zero latency mode in the wild?

Note that Eclipse compares very well versus the other Java IDEs when in
normal mode (nice!), but IDEA's zero latency mode is a consistent winner.

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223

_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev

_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev



--

Back to the top