On Thu, Apr 08, 2010 at 12:03:36PM +0000, Mike Caron wrote: > This is my plan for how Delay Loading will work. This is both for my > reference, and so you guys can comment on it. > > I believe this is necessary for a few reasons. In the future, more lumps will > be in the RELOAD format. Heroes, enemies and text boxes are prime candidates, > right off the bat. However, loading and unloading the entire text box tree > every time you show one would take a forever. And, keeping the tree in memory > might not be a good idea either (I actually have no idea how efficient the > in-memory tree is, to be honest). > > So, instead, you would load the tree once, with delay loading enabled (which > it will be by default, but can be overridden). > > RELOAD will open the document, parse the header and root node, and then stop. > The root node will be marked with a flag saying "this node is only partially > loaded", and the child node will be null. Further, RELOAD will cache the file > handle in the Doc UDT, and the file position in the Node UDT. > > When the child node is dereferenced (by GetFirstChild), RELOAD will notice > that 1. It's null, and 2. It's only partially loaded. It will then partially > load the children of the node, and clear the flag on it. Repeat for all the > children, etc. > > The important thing to keep in mind is that whenever one child is loaded, all > its immediate brethren are loaded too. This ensures that the > Next/PrevSibling() commands are always valid.
So if I understand this correctly, if you wanted to load text box 523 then just the parent node of all the other text boxes would need to be loaded, but only text box 523's data would be loaded, right? > It will also be possible to tell GetFirstChild to disable Delay Loading, > where upon it will load the entire branch of the tree. Again, this will be > useful in the situation of loading a text box, for example. Once you find the > text box in question, you know you're going to read all the children, so it > will be more efficient to load it all at once. > > One last thing. Obviously, adding a new child to a partially loaded node will > trigger loading. I think I will also add a command to go through the entire > tree and load everything, so the file can be closed. (We can't close the file > while not using it, because if it happens to change somehow, then any time we > load a partially loaded node, we risk corrupting something!) I don't understand this part. Can you explain more? If we are just closing (not writing) a document, why does it all need to be loaded? > Anything I'm forgetting here? I am pretty curious about performance for real text box data. Particularly, I am thinking of Pepsi Ranger's Powerstick Man with its jillionty-five text boxes. or VocabMosaic with its english-dictionary-in-text-box-format. How fast can we do something like: open a reload document load text box 21340 close the reload document With the fixed-length binary text box format, that operation is constant-time no matter how many text boxes there are. Seems to me that the only way we could match that level of performance is if every single reload node in the on-disk format kept an index of the offets of all its children, so you could jump to node 21340 without 21339 NextSibling calls --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
