Yeah, it definitely sounds like we need to only use the new text fields
when they're required, e.g. when RTL display is on. They need to have
feature parity with TextField so having a quirk that turns them on
everywhere is useful for testing.
I think we could get a lot of momentum behind a wrapper that implements
the TextField API, and it would reduce the API coverage/risk of
maintaining two separate LzText/InputtextSprite implementations...
On 6/27/10 11:13 AM, Henry Minsky wrote:
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] <mailto:[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] <mailto:[email protected]>
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
--
Regards,
Max Carlson
OpenLaszlo.org
