I'd like to check it in as well, it's not a big change, and then we can revisit when it's needed to use via CSS.
On Mon, Nov 1, 2010 at 1:33 PM, Max Carlson <[email protected]> wrote: > 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]> >> >> >> -- Henry Minsky Software Architect [email protected]
