'That should compass well via gzip. ' I think I was slightly west-of-north with that typo. Should be:
That should compress well via gzip. On Thu, Feb 27, 2020 at 9:01 AM Greg Dove <[email protected]> wrote: > We definitely had a discussion about this in the past. > > I think the use of fonts/font icons etc absolutely makes sense where > possible. This is common for development in javascript in general (outside > Royale), and is also often based on the application 'theme' > > For actual real embeds though, I think it makes sense to have some sort of > a solution at some point. To me, the dataURI encoded format seems like it > would make the most sense for JS. For bitmap base images (png, jpg) this > should still be base64 I think, I don't understand how that could be > improved upon. For svg maybe it can be regular text instead of base64. That > should compass well via gzip. > > Having the smallest possible javascript is not always the most optimal > approach in any given situation. > I think it was either Harbs or Josh (I can't remember) who pointed out > that competing technologies can do this 'embedding', and they intentionally > add smaller (e.g. less than 10kb) images as base64 encoded dataURIs to the > javascript or css. The reason for this is that it is more optimal than > separating it out as a separate http load. IIRC the justification was that > http request/response overhead and any other latency associated with > accessing the file remotely is heavier than the 33% extra bytes in the > base64 encoded version loaded as part of the single request for the > javascript or css file. Apparently Webpack applies this type of rule to how > it manages images although I am sure it is configurable - that part is > what I remember from the earlier discussion, because it was news to me at > the time. > From another angle, if you have your application images hosted on the same > subdomain as your application or even on a separate single subdomain in > general, I'd suggest that having many of these small images 'embedded' > could make a big difference to the startup readiness of some apps because > of the limitations on concurrent http requests by browsers (this was no > different in flash/Flex). That could also probably be relieved somewhat by > 'embedding' a lot of the smaller images. > > I don't know how any of this relates to browser cache, that might change > things as well, because after all, unless we are using cachebusters to > avoid caching, even the application javascript itself should come from > there most of the time for a stable production app. Once that has happened > I think people tend to be more concerned about overall 'performance' than > they would be about 'size'. > > my 2 cents... > > On Thu, Feb 27, 2020 at 4:28 AM Alex Harui <[email protected]> > wrote: > >> No support for embed at this time. We could make a nicer error I suppose. >> >> There is embedding support in HTML/JS/CSS, but AIUI, it requires Base64 >> encoding of the asset, which makes it larger. It just isn't clear to me >> that it is worth it. We don't generate code right now either because I >> think we should agree on what the "right" code is, if any. IMO, even >> converting embeds to an Image subclass that loads the image isn't the right >> pattern because it will cause re-layout and bad measurements at startup. I >> think smallest size, fastest performance is to convert images to SVG but >> I'm not sure we can do that automatically. In the framework itself, most >> of the symbols that were embedded were replaced by Unicode characters for >> arrows and cursors. Symbol fonts are also a possibility. >> >> HTH, >> -Alex >> >> On 2/26/20, 6:26 AM, "Carlos Rovira" <[email protected]> wrote: >> >> IIRC, we don't support Embed, or at least don't remember to see >> nothing >> about that in the last months. >> I think it's some of the things will need to be converted with the >> rest of >> needed tweaks when come from Flex. >> >> El mié., 26 feb. 2020 a las 15:02, Yishay Weiss (< >> [email protected]>) >> escribió: >> >> > Makes sense. I was wondering mainly about some emulation to keep >> the >> > syntax. It looks like the compiler is trying to do something with >> these >> > declarations, but it could be unintended. >> > >> > From: Andrew Wetmore<mailto:[email protected]> >> > Sent: Wednesday, February 26, 2020 3:30 PM >> > To: Apache Royale Development<mailto:[email protected]> >> > Subject: Re: Embed in Royale >> > >> > I don't believe Embed is required or would be a benefit in Royale, >> if you >> > are going to compile an app to run on a browser using JavaScript. >> > >> > This page [1] on Flex equivalents says >> > >> > "Embedding assets was necessary in Flex so the application could >> quickly >> > access images and other assets that were part of a compiled Flash >> SWF. To >> > make it easy to display on a button an icon that was in a SWF, we >> wrote >> > something like: <mx:Button icon="@Embed('icons.swf#our_button')"/> >> Since >> > JavaScript does not support the concept of embedding assets, doing >> the same >> > thing in Royale is a simple URL reference: <mx:Button >> > icon="icons/our_button.png"/> (once you have placed the relevant >> image in >> > the *icons* folder). >> > >> > [1] >> > >> > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Fmigrate-an-existing-app%2Fflex-equivalents&data=02%7C01%7Caharui%40adobe.com%7Cad5395cd042147026e6708d7bac7c2c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637183240009896732&sdata=LbzMSZ6uMQO5pJPivTBuer7EJC3HnOsDuEGiJbXGDuo%3D&reserved=0 >> > >> > On Wed, Feb 26, 2020 at 9:18 AM Yishay Weiss < >> [email protected]> >> > wrote: >> > >> > > Does Embed work in Royale? >> > > >> > > I’m working on a POC to port an app that has some css that looks >> like [1] >> > > this, but the compiler complains with messages such as >> > > >> > > [mxmlc] Error: The definition of base class BitmapAsset was >> not >> > found. >> > > >> > > Which makes sense as BitmapAsset does not exist in Royale src. >> > > >> > > Am I right in assuming that this is not yet implemented? >> > > >> > > Thanks. >> > > >> > > [1] >> > > .closeBtn { >> > > upSkin: Embed('/assets/16x16/button_cancel.png'); >> > > overSkin: Embed('/assets/16x16/button_cancel.png'); >> > > downSkin: Embed('/assets/16x16/button_cancel.png'); >> > > disabledSkin: Embed('/assets/16x16/button_cancel.png'); >> > > } >> > > >> > >> > >> > -- >> > Andrew Wetmore >> > >> > >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cad5395cd042147026e6708d7bac7c2c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637183240009896732&sdata=JEwrl31eWYLMBfr3JaMi0JCFRK3Z0H3VaoBQU5URGKo%3D&reserved=0 >> > >> > >> >> -- >> Carlos Rovira >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cad5395cd042147026e6708d7bac7c2c8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637183240009896732&sdata=9UlK0PWh8hDpOPzriLfrWoTduvyUHzbpTm%2BpRYEMpmE%3D&reserved=0 >> >> >>
