On Thu, Jun 05, 2003 at 10:25:39AM +0200, Juergen Vigna wrote: > >But the contained InsetTexts do, so I am not spanking 'slow InsetTabular as > >created by Juergen' but 'InsetTabular as container of lots InsetTexts' > >[Although I'd think that there is some unnecessary fat in InsetTabular, > >too...] > > You may have a point here, althought I don't know where I would optimize > something I didn't already consider :(
I think it's not exactly a tabular problem per se, but a result of the broken core architecture (like inset locking and update). You have to put in too much code just to make it work. Look at things tables as 'containers of cells' should not be aware of in theory: 31 lines for InsetTabular::setFont(), 5 of which contain the necessary loops over all cells. More than 20 lines are 'glue' to undo, update and insetlocking. That's the 'fat' I am talking about. > >In practice, I'd consider this a premature optimization. This readiness > >has resulted in a lot of code which is not exactly easy to read or to > >modify, especially when it comes to conceptual changes like the conversion > >from an 'update based drawing' to the 'two phase drawing'. > > The only change to make to "rip" that functionallity would be to have > instead of a map<LyXText, BufferView) a single LyXText entry I don't > think that you add a lot more redability if you change this. That's the patch I posted this morning. Kills 134 lines out of 2540. Five percent. At least a starter. I think there's more in there. update() can go, 60 lines. Include removing all other update related stuff, this should easily reach 300 lines. Inset locking is 210 lines alone for tha actual handlers, not counting the 'user code'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
