Rev 5482 adds @colorcache directive and completes the color caching code. Please test
17 views
Skip to first unread message
Edward K. Ream
Oct 3, 2012, 5:46:29 PM10/3/12
to leo-e...@googlegroups.com
Rev 5482 contains major improvements to the color caching scheme. Please test it and report any problems immediately.
Here are the details:
1. The *only* way to get caching for a node is to add the @colorcache directive to the node. Descendants do *not* inherit the @colorcache directive, and there is no @nocolorcache directive. Besides being the simplest thing that could possibly work, I think it is perfectly reasonable: we expect most .leo files to have small nodes and adding an @colorcache directive to a node seems like a small matter. This choice can be revisited easily if it causes problems.
2. Because caching now only happens explicitly, I removed the g.cache_color_info switch. This should be perfectly safe: Leo's default operation will be no color caching.
3. The new code eliminates all the kludges from write_colorizer_cache and rehighlight_with_cache. In fact, it seems perfectly safe to save and restore the layout.additionalFormats info. It looks like I mistakenly concluded that underlying data was being deleted. The hard crash I took was most likely due to some other programming blunder ;-) This is very good news: it means that *all* formatting information is saved and restored quickly, without having to understand its internal format. Similarly, the prototype read/write buttons in test.leo are as simple as possible.
At present, I plan no further color caching work: the present code is as simple as can be imagined. But I'll be happy to revisit the code if there are problems.
Edward
Here are the details:
1. The *only* way to get caching for a node is to add the @colorcache directive to the node. Descendants do *not* inherit the @colorcache directive, and there is no @nocolorcache directive. Besides being the simplest thing that could possibly work, I think it is perfectly reasonable: we expect most .leo files to have small nodes and adding an @colorcache directive to a node seems like a small matter. This choice can be revisited easily if it causes problems.
2. Because caching now only happens explicitly, I removed the g.cache_color_info switch. This should be perfectly safe: Leo's default operation will be no color caching.
3. The new code eliminates all the kludges from write_colorizer_cache and rehighlight_with_cache. In fact, it seems perfectly safe to save and restore the layout.additionalFormats info. It looks like I mistakenly concluded that underlying data was being deleted. The hard crash I took was most likely due to some other programming blunder ;-) This is very good news: it means that *all* formatting information is saved and restored quickly, without having to understand its internal format. Similarly, the prototype read/write buttons in test.leo are as simple as possible.
At present, I plan no further color caching work: the present code is as simple as can be imagined. But I'll be happy to revisit the code if there are problems.
Edward
Edward K. Ream
Oct 3, 2012, 6:06:12 PM10/3/12
to leo-e...@googlegroups.com
On Wednesday, October 3, 2012 4:46:29 PM UTC-5, Edward K. Ream wrote
> Rev 5482 contains major improvements to the color caching scheme. Please test it and report any problems immediately.
A note about performance. The code that saves and restores formatting data is quite fast; they take about a tenth of the time it actually takes to redraw the body text of a node. Alas, this does not speed up node selection as much as I had hoped.
Indeed, even if restoring the syntax coloring data took *no* time it would still be fairly expensive to redraw all the text of a large node. As most of you no doubt know, rendering text is a fantastically complicated affair. The Qt rendering code is written in C++, but even that code takes more time than we would like.
As Ville and I have both pointed out, selecting a large node is similar to loading a file in a vim or emacs buffer. Users don't notice the slight delay in colorizing those buffers because the initial (slow) colorizing happens only once. So it would be if you only stayed in a single node with Leo. When inserting or deleting lines or characters, Qt (or vim or emacs) can blit bits around in the video buffers, so such operations are quite fast. But there is simply no alternative to loading the buffers initially.
One last thing. At present, color caching speeds up Leo when you move *past* a node. But when you start editing a node Leo must once again fully re-init the Qt colorizer, which takes time. So typing the first character *must* be slow, but after that typing will be fast again.
Edward
> Rev 5482 contains major improvements to the color caching scheme. Please test it and report any problems immediately.
Indeed, even if restoring the syntax coloring data took *no* time it would still be fairly expensive to redraw all the text of a large node. As most of you no doubt know, rendering text is a fantastically complicated affair. The Qt rendering code is written in C++, but even that code takes more time than we would like.
As Ville and I have both pointed out, selecting a large node is similar to loading a file in a vim or emacs buffer. Users don't notice the slight delay in colorizing those buffers because the initial (slow) colorizing happens only once. So it would be if you only stayed in a single node with Leo. When inserting or deleting lines or characters, Qt (or vim or emacs) can blit bits around in the video buffers, so such operations are quite fast. But there is simply no alternative to loading the buffers initially.
One last thing. At present, color caching speeds up Leo when you move *past* a node. But when you start editing a node Leo must once again fully re-init the Qt colorizer, which takes time. So typing the first character *must* be slow, but after that typing will be fast again.
Edward
Reply all
Reply to author
Forward
0 new messages