IIRC, in Flash, a string lookup is actually faster than a string literal. I was wondering if Closure would in-line it or look it up so we could hack that string. Or maybe if we define it as a "var" instead of "const" it will always look it up, but not sure.
I think that for swf bytecode output and for GCL release mode build, both have consolidated string tables approach where common string literals are held as a single copy. I'm not sure if that has a small size threshold (e.g. 2 chars like 'px' might be more compact expressed as a literal each time it repeats instead of using a reference to a string table entry) As an aside: at one point I mentioned that some of the reflection data might be best expressed as things like 'org.apache.royale.' + 'collections.' + 'ArrayList' because perhaps it could reduce the overall size of the string references in GCL release mode, because it would (I guess, not verified) reduce the number of unique longer strings in the table. But it might depend on whether GCL 'optimizes' the string concat of constant strings to a single string as another type of optimization or not, before adding to its version of the 'string table'. On Tue, Jan 15, 2019 at 7:36 AM Alex Harui <[email protected]> wrote: > The string literal "px" is scattered throughout our code. For example: > > UIBase.as > this.positioner.style.height = value.toString() + > 'px'; > > This could be changed to: > > public static const CSSUnits:String = "px"; > > this.positioner.style.height = value.toString() + > CSSUnits; > > IIRC, in Flash, a string lookup is actually faster than a string literal. > I was wondering if Closure would in-line it or look it up so we could hack > that string. Or maybe if we define it as a "var" instead of "const" it > will always look it up, but not sure. > > Also note that other parts of our code should be reacting to the size of > elements (which would react to browser changing fonts). So there may be a > different solution entirely, which is to see where in the code the things > that didn't change size were making assumptions. > > Thoughts? > -Alex > > On 1/14/19, 10:29 AM, "Harbs" <[email protected]> wrote: > > > > On Jan 14, 2019, at 8:04 PM, Alex Harui <[email protected]> > wrote: > > > > Harbs, > > > > What did you learn about constants and in-lining regarding Closure > Compiler? Could we put "px" in a variable/constant and have the option to > replace it with "em”? > > I can’t think of a way to do that off-hand. > > > That said, are we sure that you can just switch to "em" and all > other computations will "do the right thing”? > > No. I don’t think we can be sure of that at all. That was the gist of > what I was saying about it being a bad idea. > > > > My first reaction is that Basic is basic and works in pixels and > that adding other units can happen in other component sets and beads. > > Maybe that’s the way to go, but I would prefer some way to change the > units via some kind of bead or something on standard sets. Not sure what > that would be though… > > > Of course, I could be wrong, > > -Alex > > > > On 1/14/19, 8:39 AM, "Harbs" <[email protected]> wrote: > > > > There are tons of discussions on the web about the pros and cons > of pixels vs em/rem. Some examples:[1][2][3][4][5] > > > > My takeaway is that there’s no one right answer. For predictable > layout, pixels is safer, but for better reading with accessibility, em/rem > might work better. > > > > Simply changing from pixels sounds like a very bad idea. For > pixel perfect web apps pixels is probably the better choice. It might be a > good idea to add the possibility of using em and/or rem, but adding more > methods to UIBase is probably not the way to go about it. > > > > Maybe all the specifications of “px” should be changed to some > utility function and a mixin could determine the actual value. > > > > My $0.02, > > Harbs > > > > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbenfrain.com%2Fjust-use-pixels%2F&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=WFiUn4fMJG4tOJvnzNU1XF2c0wDnEZooVHSRCxYvv14%3D&reserved=0 > > [2] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-px&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=4Yo2A5fUq7KidRTM%2FDulBnElY2wK3QnWIYq0aNCKs84%3D&reserved=0 > > [3] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percent&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=CIOgFzac6y50hSHsfXludv5M%2FUNhgiVti%2BenoigMHDo%3D&reserved=0 > > [4] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=a6ohFKIGRTnga3ZqT%2FjC5KveWWl%2BamoqxqBd3Cu1Dhc%3D&reserved=0 > > [5] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-px&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=bBffOQLT7DPeDr1NStzGyX20vFeRitOreVSO2RsMRFY%3D&reserved=0 > > > >> On Jan 14, 2019, at 5:04 PM, Carlos Rovira <[email protected]> > wrote: > >> > >> Hi Mark, > >> > >> very good question. And I don't know what would be the best... > >> > >> Hope others (Alex, Harbs, Piotr, etc...) could give some thoughts > about > >> this since I'm not sure. > >> > >> To put people on track; Mark states that using font size (only) > browser > >> increase/decrease (notice that Firefox has a built-in control, but > Chrome > >> needs a plugin), makes Apache Royale > >> fonts bigger or smaller while the rest of drawings are not > affected. If we > >> change from PX to EM units, seems Mark gets right results. > >> > >> So, the question is...how should we adapt Royale codebase to manage > this? > >> > >> Current width/height in UIBase, uses PX and is hardcoded...could we > make > >> some decoupling or "plug" the right units as we want?, so instead > of "px", > >> we have a constant or some modifier that could be configured in > some part > >> (Maybe in Application), so we can set to EM instead to PX?? > >> > >> I think we need some config here, but that respect actual config, > so people > >> can use actual PX or change to EM if they want. For example, I > think Jewel > >> should change to use EM in a global way. > >> > >> Thanks > >> > >> > >> > >> El lun., 14 ene. 2019 a las 13:39, Mark Kessler (< > >> [email protected]>) escribió: > >> > >>> Carlos, > >>> I can give it a shot when I'm at home. However, what about the > >>> direct width/height assignments. Should they do EM assignment too > or > >>> should there be a new widthEM heightEM property added? > >>> > >>> -- > >> Carlos Rovira > >> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&sdata=HjIHZ7QfXVtOTIkk3i%2FrUWzlWFGmsnvMeyO%2B4gtwFxA%3D&reserved=0 > > > > > > > > > >
