Hi, On 11/29/2011 12:59 PM, cbrown wrote: > I'm currently investigating using image combining within my application, > specifically the b64 encoded type. > > I have setup a test config that contains a couple of images and have > successfully built and run this. > > My application uses parts and I notice that the encoded images are written > both to the .b64.json file that I specified in the image.json config file > and into the part files. I find that encoded data for the same images are > written into more than one part file which means that I am downloading the > encoded image data multiple times. > > I've been trying to work out what causes a specific image to be written to > multiple part files, but have not yet been able to understand the > relationship between the encoded image data and the part files.
The relationship is easy enough: Resource data is added to a part if the part contains classes that use those resources. In your case that means, whenever a class uses an image that is contained in your combined image, the combined image is added to the corresponding part. If there are multiple parts where this hold true, multiple parts will contain the combined image. This produces duplication of data, which is tolerated as the parts need to be independent (you never know whether a part is being loaded during runtime, and if so, when). For our classical resource data this might be negligible, but granted, in the case of b64 combined images it leads to a distinct penalty. We could extract shared resources e.g. into the boot part, so they would only be loaded once but then they would always be loaded, even if the requiring parts are never loaded. So you'd run into penalties again. Currently, there is no synchronisation in place. One way to work around this could be that you change the definition of your combined image, and maybe split it up into two in such a way that one of your parts uses only one, and the other part only uses the other. This would reduce redundancy. Or, if your combined image is used throughout all of your classes, you could add it to one of the head classes of your 'boot' part, and remove the references to it from your other classes. Remember that "reference" in this context *only* means the #asset declarations in class files, so by changing them you change which resources end up in a part. You don't have to touch your JS code. b64 combined images are still somewhat experimental, in that we are trying to find out what the best deployment scenarios might be. If you feel stronly about your issue, open an enhancement bug for it. T. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
