Has anyone noticed that images are grossly inflated in the client cache? I use PNGQuant to compress my .png images (which is really good and extremely fast, btw). I expected that Ignition would inflate somewhat for actual image object dimensions, but 1200% bigger? What is the image processor in Ignition? I think there should probably be options for compression percentages (yes I know compression can be slow). Also, if the original image is the correct size for the full screen client image object, then why would it cache a same-sized image that is significantly larger? I imagine there are technical reasons for all this, but it seems a bit heavy.
The original is the 20k files, but the cached images are quite a bit larger.
Although this is not significant for projects containing few images, my current project has over 10k images which are changed out at fairly fast intervals... as quick as 50msec. Not only is size an issue, but the speed of the image processing to make the cached image is quite slow which causes a "jerkiness" the first time a client displays the images.
Can someone explain the "Load In Background" behavior on the Image object a bit better than the manual? What would be the advantage/disadvantage of using this option.
Ign 7.9 Manual: Controls whether or not the image loading takes place on the UI thread or a background thread.
I don’t know the internal mechanism, but it would be pointless to cache as anything other than 24bpp or 32bpp full size, cuz that’s what Swing needs to display. Have you inspected the cache files content?
Dang Java! That explains the giant leap in size as mine are indexed 8bpp. The reason I compress is because there are SO many images and it takes forever on my remote connection to upload. That snip in the post is from the image cache.
I recommend you not use the image object. Script your operation with the paintable canvas, where a background thread decompresses/scales your PNGs and delivers to a JComponent client property. No cache on disk. (Pointless if changing often, IMNSHO.)
Hmm… Interesting. I will have to do some experimenting with that! This is a faux 3D animation script for manufacturing operations hidden from operator view that display the images based on servo positioning. Exactly like one of those books where you flip the pages to simulate animation.
Aha… I thought I must have misunderstood him. Like I told Phil, I am up for experimenting with it. If it turns out that real time rendering can give me cache speed smoothness, then I will definitely shift to that tech as the cache route is problematic for the client memory also.
