[Lazarus] [patch] lhelp scrolling slowness - I might have found it

[Bernd]

2011/12/25 waldo kitty <wkitty42 at windstream.net>:

> a noticeable difference as in how? faster processing or that more "nodes"
> are being properly processed and placed into the resulting output files?

Faster scrolling. I am using it on an old Pentium-M with 1.3GHz and
before there were pages that were effectively "unscrollable" for me.
One extreme example that makes it very obvious is  if you look up the
help for the RTL function Format() in rtl.chm. Before the patch it
took around 1 second for every scroll event, If I used the mouse wheel
then the GUI was frozen for 1s, then displaying it scrolled 3 lines
up, then frozen again for one second, then another 3 lines, etc. Now I
can scroll this same page very smoothly, no freezing and waiting
anymore.

BTW in my first post I mentioned css property names, this was wrong,
this was before I digged a bit deeper into it to understand what this
function actually needed for: It is looking up html tag names in a
list of names to get a reference to the css property object that is
attached to a tag name. for example there might exist a css directive
like p: {color: #00ff00;} then while parsing the css it will use this
function to look up the property object for 'p' and set its FColor to
#00ff00. Later when rendering the page it will again use the same
function on every node in the html tree that it encounters to get the
properties object for this node (for every <p> in the html (and for
any other tag) it will again up the tag name to retrieve the property
object (TCSSProps object) to know the node's color (and other
properties)).

For some reason this is done on *every* scroll event again and again.
If I understand it correctly then after the HTML is parsed then there
exists a tree of TIpHtmlNode objects and each node holds a reference
to the appropriate TCSSProps object, it should not be needed to look
them up more than once for each node upon construction of this node
unless for some reason the entire html tree is is destroyed and built
up from scratch again and I don't see why this should be necessary on
every scroll event. The next step should be to find out what exactly
is going on during a scroll event that causes this to happen every
time.

Bernd