Chris Bowditch wrote:
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

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
- 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.


Reply via email to