Just to play devil's advocate... What if we just put in Henry's bidi
cascading (based on my hacks) in for now, and see how it performs? We
could defer the optimization phase until later. I'm concerned we may be
overthinking this and it's delaying forward progress on other things...
On 11/1/10 9:35 AM, Henry Minsky wrote:
That's a major issue I agree. I'm working on pushing the sprite creation
to init() method, but just moving all the stuff out of the
LzText.construct method had a number of bugs; there's some stuff that
happens in the LzText.construct method that can side-effect the sprite
(via setters) , and I'm trying to figure out which calls break as
they're moved into the init method, and how to defer them.
On Mon, Nov 1, 2010 at 11:41 AM, P T Withington <[email protected]
<mailto:[email protected]>> wrote:
My big concern is that in a large application, you'll start up,
create a zillion text sprites, then the style sheet bindings will be
applied/cascade/inherit, and all zillion will have to be
re-created/garbage-collected (or possibly leaked, if we are not real
careful, due to the complexity of gc-ing across the runtime DOM API).
On 2010-11-01, at 11:24, Henry Minsky wrote:
> I'm trying out just swapping out the textfield object inside the
sprite
> first, to see if that will work, because it's been proving to be
pretty
> messy trying to move the actual creation of the LzTextSprite to a
later
> phase.
>
> On Mon, Nov 1, 2010 at 8:23 AM, P T Withington
<[email protected] <mailto:[email protected]>>wrote:
>
>> It's not so much that we want to change it at runtime, just to
have it
>> inherit.
>>
>> But even if we are not supporting changing it at runtime, to have it
>> inherit, especially to be able to style it with CSS, we have to
defer the
>> creation of the sprite. CSS bindings don't happen until just
before init()
>> time, whereas normally we are creating the sprite at construct()
time.
>> <inputtext> very often creates the wrong kind of sprite at
construct(),
>> only to have to re-create it, once the value of `multiline` is
finally
>> known.
>>
>> The solution Henry and I are favoring, since <text> nodes cannot
have
>> children (LPP-1218), is just not allocating the sprit for text
until init().
>> That way, any inherited or CSS-bound setting for `direction`
(the CSS
>> property for text direction) will be known.
>>
>> As a bonus, it may fall out that you can change the setting of
`direction`
>> at runtime and just create a new sprite, the same way we do in
<inputtext>
>> for `multiline`.
>>
>> On 2010-11-01, at 00:19, Max Carlson wrote:
>>
>>> We've had font styling attribute inheritance from parent nodes
for a long
>> time. The canvas always has a default value that's inherited.
One thing
>> that was really annoying was not being able to set the canvas
font styling
>> attributes and have the values update...
>>>
>>> I'm torn on this one - it seems like we really need the same
behavior for
>> the common case of inheriting from the canvas. Not sure about
being able to
>> change the TLF attribute at runtime...
[snip]
--
Henry Minsky
Software Architect
[email protected] <mailto:[email protected]>
