On 03-Aug-12 02:10, Walter Bright wrote:
On 8/2/2012 1:41 PM, Jacob Carlborg wrote:
On 2012-08-02 21:35, Walter Bright wrote:
A good IDE should do its parsing in a separate thread, so the main user
input thread remains crisp and responsive.
If the user edits the text while the parsing is in progress, the
background parsing thread simply abandons the current parse and starts
over.
It still needs to update the editor view with the correct syntax
highlighting
which needs to be done in the same thread as the rest of the GUI.
The rendering code should be in yet a third thread.
OT:
It never ceases to amaze me how people miss this very simple point:
GUI runs on its own thread and shouldn't ever block on something (save
for message pump itself, of course). Everything else (including possibly
slow rendering) done on the side and then result (once ready) swiftly
indicated on GUI.
Recent Windows 8 talks were in fact nothing new in this regard, but now
even API is made so that it's harder to do something blocking in GUI thread.
An editor I wrote years ago had the rendering code in a separate thread
from user input. You never had to wait to type in commands, the
rendering would catch up when it could. What was also effective was the
rendering would abandon a render midstream and restart it if it detected
that the underlying data had changed in the meantime. This meant that
the display was never more than one render out of date.
Although the code itself wasn't any faster, it certainly *felt* faster
with this approach. It made for crisp editing even on a pig slow machine.
--
Dmitry Olshansky
