[Laszlo-dev] new textsprite implementation

[Max Carlson]

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
> <hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>> 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
>     hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
>
>

-- 
Regards,
Max Carlson
OpenLaszlo.org