I found a somewhat more efficient way to append arbitrary HTML text to a
TextFlow.
It's possible to create a new TextFlow for the content you want to append,
and then
copy it's child 'FlowElement's to the main TextFlow, e.g.,
public function appendText( t:String ):void {
t = t.replace(linebreakPat, '<br/>');
var aflow:TextFlow = TextConverter.importToFlow(t,
html ?
TextConverter.TEXT_FIELD_HTML_FORMAT : TextConverter.PLAIN_TEXT_FORMAT,
config);
while (aflow.numChildren) {
textFlow.addChild(aflow.getChildAt(0));
}
textFlow.flowComposer.updateAllControllers();
}
This is a lot faster than regenerating the whole TextFlow, and mostly works,
except it always creates a linebreak before the new content. That may be
fixable by merging the last SPAN or P or whatever element it is using.
It's still seems noticably slower than setting the text in the old TextField
though. It takes about one second between clicking on the <canvas> object
and seeing the debugger output appear, I'm not sure what the delay is due
to.
It seems like a step backwards if our text output is slower than the
existing
TextField object. So it may be that we really do want to keep the existing
LzTextSprite
implementation and also offer a TLF-based text object as well, when
bidirectional text is
needed.
I guess I had better get some timing measurements on how long it takes to
execute
a setText and addText for TextField vs the new TLF stuff.
On Sun, Jun 27, 2010 at 11:37 AM, Henry Minsky <[email protected]>wrote:
> I've got the mostly debugger working with the new text sprite, except for
> something is still a little broken with vertical scrolling.
> The simple test case works (test/lfc/maxscroll) , but the debugger text
> pane itself is not scrolling quite right. It may be that
> since the debug pane uses some very old scrolling code, it may be depending
> on some other behavior.
>
> But there's a big issue which is the efficiency of setText to append text
> onto the field. When I click on canvas object to inspect
> it in the debugger, it takes four or five seconds to display the result,
> which is almost certainly due to calling setText repeatedly,
> which causes the whole text flow to be recreated. We need to find out how
> to efficiently append text into the textFlow rather
> than reimporting the whole thing from HTML for each call to setText.
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> [email protected]
>
>
>
--
Henry Minsky
Software Architect
[email protected]
