Hmm OK I am going start making a TextField-compatible wrapper. I agree that
it's too much risk and maintenance headache to try to maintain separate
LzTextSprite implementations.

Maybe if we release a version, we can get some help from Flash developer
community to maintain it as well.




On Sun, Jun 27, 2010 at 2:41 PM, Max Carlson <[email protected]> wrote:

> 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
>



-- 
Henry Minsky
Software Architect
[email protected]

Reply via email to