Description Mike Wilson 2001-10-11 14:20:53 EDT

On Windows, the StyledText widget is wider than the text it contains.
The width seems to be estimated as if all the text was bold.
There is a note that mentions the estimate is used for performance reasons.
Since there is code (styledTextWidth()) that correctly determines the width, 
can it be exposed so that users of StyledText can configure it to always compute
the exact text width? 
I am using it to display F1 infopop text, and the text is fairly small to not have a performance penalty.

NOTES:

KH (5/31/2001 12:04:08 PM)
	Styled text supplied by SWT.

	McQ (01/06/2001 8:58:02 AM) -
		We will not get to this by June.

	McQ (26/06/2001 2:27:59 PM) -
		We should at least try to fix this.

KR (7/9/01 11:59:02 AM)
	If accurate line width calculation is a priority we could introduce a widget creation style 
	bit for this.

KR (7/16/01 11:40:01 AM)
	Benchmarks using SwtStyledTextUseCase. Page scrolling OS.java (win32) from top to bottom
	using the keyboard. Java colors and styles enabled, window maximized (43 lines visible).

	Result columns are method, calls, total time
	Current, inaccurate line width calculation:
		StyledText.calculateContentWidth(int, int)		106		1820
		StyledText.handleKeyDown(Event)					106		2475

	Accurate line width calculation, no optimizations:
		StyledText.calculateContentWidth(int, int)		106		4090
		StyledText.handleKeyDown(Event)					116		4614

	One possible optimization would be to filter out line styles with a regular font style when
	measuring the line width.
	However, the performance improvement won't be sufficient to come anywhere close
	to the original, inaccurate, speed. I tried a quick implementation of the filter that works
	with the existing code by creating a new style array. Creating that new array is slower than 
	the existing filter (which simply returns null instead of an array when there are only regular 
	fonts on a line).
	The most effective optimization would be to cache the width of *every* line and only recalculate
	when that line is edited. However, this is time consuming to implement since we would have 
	to change the cache whenever lines are deleted or inserted. One thing to keep in mind is that
	there will be a delay the first time a line/page becomes visible because the accurate calculation 
	will be done. 
	We should look into doing this at a later time. Will keep inaccurate line width calculation in 
	the mean time.

	McQ (17/07/2001 9:41:54 AM) -
		From an email I sent to LK and KR:
			Basically, the only thing you can do is remember the line width for each line as
			it is rendered, and pre-compute it (with text measuring calls) for lines that have
			not been. The pain is that you have extra stuff to manage as text is typed, cut,
			pasted, etc., but the benefit is that it's only slow once. Since you are doing the
			double buffered thing, you are computing these lengths anyway, so "all" you have
			to do is remember them.

			You can also delay the computation until it's actually requested the first time.
			This makes the two most common cases fairly reasonable:
				- a small amount of text in a "right sized" text window -- it's ok to compute
				  the line length for every line since there aren't that many.
				- a large amount of text in a window with a "right sized" horizontal
				  scrollbar -- since you don't compute the width until you hit the line,
				  there isn't a big up front cost.
			(Note: The difference between these two is that, in the first case, the user
			 called API which forced you to compute the whole thing.)