BTextView: remove useless and heavy computation

There is no point in computing line breaks for a 10px wide text view and
it takes a long time because it needs a lot of linebreaks. The view
eventually gets laid out properly.

This may cause regressions, the TODO here is very old and I don't know
to which "other parts of the code" it refers. Possibly they were
rewritten, possibly not. In any case, there is no point in keeping this
nonsense initial text rect computation, it's better to fix the actual
problems.

Fixes #5582 (which was not locale-related, after all)

src/kits/interface/TextView.cpp

@@ -3708,6 +3708,12 @@ BTextView::_RecalculateLineBreaks(int32* startLine, int32* endLine)
 {
 	CALLED();
 
+	float width = fTextRect.Width();
+
+	// Don't try to compute anything if the text rect is not set
+	if (width <= 0)
+		return;
+
 	// are we insane?
 	*startLine = (*startLine < 0) ? 0 : *startLine;
 	*endLine = (*endLine > fLines->NumLines() - 1) ? fLines->NumLines() - 1
@@ -3716,13 +3722,6 @@ BTextView::_RecalculateLineBreaks(int32* startLine, int32* endLine)
 	int32 textLength = fText->Length();
 	int32 lineIndex = (*startLine > 0) ? *startLine - 1 : 0;
 	int32 recalThreshold = (*fLines)[*endLine + 1]->offset;
-	float width = max_c(fTextRect.Width(), 10);
-		// TODO: The minimum width of 10 is a work around for the following
-		// problem: If the text rect is too small, we are not calculating any
-		// line heights, not even for the first line. Maybe this is a bug
-		// in the algorithm, but other places in the class rely on at least
-		// the first line to return a valid height. Maybe "10" should really
-		// be the width of the very first glyph instead.
 	STELine* curLine = (*fLines)[lineIndex];
 	STELine* nextLine = curLine + 1;