Quote:
Originally Posted by kovidgoyal
So every time either the user or some javascript makes a change to the DOM/CSS you propose re-indexing the entire tree (at least upto the current point?) For example, calibre's EPUB viewer actaually supports a reference mode that changes the DOM and the CSS of document elements on the fly in response to user interaction.
|
Does the Epub specification support documents that can dynamically alter themselves? If it does, then regardless of your renderer, you would have to either re-index the entire tree up to your current point or accept that your page boundaries may be inaccurate.
If your viewer allows the user to change the DOM/CSS then it faces exactly the same issues. On a PC, that's not a problem. On a resource restricted device such as a low-end e-reader, you have to ask yourself if providing such functionality is going to provide the user with a poor experience.
If your software does supports changes to the DOM or CSS, there is no reason why it cannot work to update indexes in quite an efficient manner. Certainly any change that will affect indices can be transformed into a delta and that applied over the index (which itself is a relatively small set of structures, so has minimal performance penalty). In that case, re-indexing will be far more efficient that a full re-parse of the document - which is what you're proposing.
Quote:
Originally Posted by kovidgoyal
The scheme you propose might work well for static content that the user never interacts with/modifies but not for anything else. And frankly making that trade-off (removing size restrictions but making interactivity much slower) is just wrong.
|
Absolutely untrue - in fact quite the reverse. If you manage document updates as deltas to the index information, then having pre-indexed documents gives faster updates than un-indexed ones that will require a complete re-parse to ensure you are displaying the correct information.