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]
