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