What? Why???
I’m guessing that they are ‘in memory’ first simply because they are part of the EXE, (just like all the code in modules you may never call. )
Then when needed, instead of Xojo using these resources from wherever they ended up as part of the EXE, they were copied to another memory address and used from there.
In the case of pictures, if the embedded item is a PNG file and you want to display it, it has to be unpacked to its uncompressed form to become a bitmap.
Unused code in modules is handled by other Windows development platforms by putting the code into DLLs.
These are external until required.
But Xojo cant do that.
The new 2015 method used by Xojo for pictures etc works in a kinda-similar fashion to DLLs: left external until required, then loaded into memory on demand.
I still feel this is ‘smoke and mirrors’ when Xojo claim that this reduces the EXE size.
The disc footprint is surely the same.
(And much larger than last year, because of this text handling stuff they added recently.)
I imagine (havent tested) that this might cause a slowdown if your code doesn’t make a point of loading up pictures into global variables when it starts up. Because otherwise there will be a disc access delay when you first need a picture, and perhaps a disc access every time you need the picture…
No, only once.
The big advantage comes if the user doesn’t encounter one or more of the images at all. Imagine there are 50 images, 25 are used every time the app runs and the rest only occasionally. One of the benefits is that the occasional images may not load at all if the user doesn’t access that part of your application.