Two days ago I took a look at the QSyntaxHighlighter (qsh) source code: http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/text/qsyntaxhighlighter.cpp
I was a bit surprised to see that this is just a thin wrapper over QTextDocument methods. Yes, qsh is a useful wrapper, but Leo could do without it. If we aren't tied to the qsh code, we are free to repackage it in different ways. If nothing else, this is a useful thought experiment! The *vital* thing to keep in mind in the following discussion is that the vast bulk of Leo's present (complex!) coloring code will remain unchanged. I am only considering a slight repackaging of Leo's code. Suppose we did syntax coloring in a separate thread? This might solve the performance problems completely! Body text would appear *instantly* in the body pane, and the coloring would be applied "later". Of course, there are issues: all the "real" coloring must be done in the gui thread, so there is non-trivial coordination required. In particular, the code would have to queue results that would then cause calls to setFormat in the main (gui) thread. This morning, when I arose, I saw a simpler alternative. Suppose Leo does all coloring at idle time? We get the same benefits, but with less complications. No need for a separate thread: the idle-time code "simulates" a separate thread. This is exciting. In essence, we just need to do the processing of the over-ridden rehighlight method at idle time. That is, Leo would recolor just one line at each idle time. This keeps the response excellent. It might be possible to get a prototype working in just a few hours. I'll do so asap. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
