An interesting idea... but hasnt this already been done in more detail in TextLM.getNextBreakPoss? So why should the renderer have to do it again (although in less complexity)? I would rather have layout do this, otherwise this logic would have to live in every renderer.
There is a tradeoff between avoiding recomputing the word width and carrying it around for probably some significant time.
I dont understand this bit fully. Are you saying its inefficient to carry around data items such as dAdjust, TSAdjust, etc? I would definitely say it is better than re-computing them in the renderer.
As you noticed, the TextLM.getNextBreakPoss examines the content character by character for calculating the break possiblities, thereby also keeping track of accumulated text width for the line.
The break possiblities, or something else, could be marked whether they delimit adjustable space, refer to the x-offset or something equivalent and the text snippet and all passed to the renderer, thereby avoiding reparsing the line for adjustable space and recalculating offsets/widths. The point is that this data could as well be discarded after the line break is finalized. The most convenient way to keep it around until rendering without copying is as a list of small objects. Because redering doesn't start until a full page is laid out, this would lock up a significant amount memory. Whether it matters, compared to other problems, is yet to be determined.
Summarizing: we have a bunch of strategies: - Keep data associated with adjustable spaces from layout for rendering, thereby avoiding recalculation - Discard the data as early as possible, thereby reducing peak memory usage - Use something in between: copy into a compact representation, or discard part of the data. I lean somewhat to the first strategy, because memory is usually more of a problem then bare performance. I also have the gut feeling this approach makes integration of leader expansion easier. Of course, if someone implements several possiblities and runs benchmarks, or even makes it a user choice, I wont object.
J.Pietschmann
