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