LiveCode Forums.

I’m having a problem with LiveCode - I’ve been working on something for a while, and I was hoping to share what I had yesterday with a friend. So I built a version as a standalone, and started to notice real problems between how the standalone behaves and what the development environment shows me.

What the application does is import an MPO file from a Fuji stereo camera, separates the left and right frames and displays them in a window. You should them be able to make various adjustments and output a stereo card image. This works well in the development environment, but it falls over completely when the application is exported as a standalone.

Here’s the problem. This is the screen after I load an MPO file in the development environment (ie running LiveCode):


The application allows me to increase the size of the two images, so I do this using a slider in the inspector palette. I get this in LiveCode:


Now, compare the screens with those in the standalone app. There has been no changes to the code between these two states.
Straight after loading:


And then after the images are scaled:

Something is not right here - but I’m not sure what - hence me posting this. The image size appears to be unchanged compared to the “good” result. It has done *something* because the inner shadow has appeared (during the scaling effects etc. are dropped help speed things up a bit). That tells me that it's processed the image, but maybe the weird appearance is something to do with the container not scaling?

I’m wondering what it is that I should be looking to solve this problem, and how to debug the standalone fully, as obviously there are problems there which need addressing. The headache is that this (and a couple of other performance issues) are not consistent between what LiveCode shows (which is how I expect it to work) and what the standalone is doing (it not what I expect). So to debug, I have to build, test, fix, build again. This is in LC Community 8.0.0, and also noted similar problems in 7.1.4 on Mac OSX 10.11.4

I’ve already addressed a few problems which seem to stem from using code along the lines of "put text of image A into image B" instead of using imagedata - but again, why should that be an issue in the standalone when it works correctly in the LiveCode development environment?

There also seem to be other performance issues which adversely affect the standalone as opposed to the LiveCode preview, and a few other problems with importing other image formats (such as TIFFs) which, again, are a problem in the standalone but not in the development environment.

Somewhat baffled by this at the moment. I’ll keep looking myself, but I’m hooping that someone has seen this kind of thing before and can point me in the right direction.

Hi HairyDalek,

the oblique lines look suspiciously like the imageData does not fit the image size.
Try to make sure your imageData length is width*height*4 of the new image dimensions or set the imageData before enlarging the image.
Of course this is a guess.

I’ve already addressed a few problems which seem to stem from using code along the lines of "put text of image A into image B" instead of using imagedata - but again, why should that be an issue in the standalone when it works correctly in the LiveCode development environment?

That should not be a problem at all. ???

Kind regards
Bernd

hairydalek wrote:I’ve already addressed a few problems which seem to stem from using code along the lines of "put text of image A into image B" instead of using imagedata - but again, why should that be an issue in the standalone when it works correctly in the LiveCode development environment?

Obviously the image has an alpha channel that is written when building the standalone and used by "the text of image".
The IDE uses as paintcompression by default PNG, the standalone by default RLE. That makes the difference.

You could try in the first card's script:
And instead of "put text of image A into image B" (don't change the order of these two lines!!) [Edit. Thanks to Bernd for pointing out an error in the first version of this post.]

Hi Hermann,

The IDE uses as paintcompression by default RLE, the standalone by default PNG

that used to be the case, not anymore. Try in the message box after starting LC is says png
I don't remember when it changed, just tried LC 6.1.3 and it uses PNG as default.

set paintcompression of this stack to RLE -- or PNG

this throws an error, paintcompression is a global property, not one of the stack. this works.

Kind regards
Bernd

Hi Bernd.
Yes, of course, you are right with the property. [I use it often together with "acceleratedRendering" which is a stack property. That produced the error, sorry. Corrected above.]
Also I switched RLE and PNG for the default values [also corrected above].
But the difference is there and I think the difference in the paintCompression causes the "bug" here. One could give it a try.

8.0.0-dictionary wrote: ... If an image's alphaData property contains any value other than 255 (opaque), it is automatically recompressed in PNG format to preserve the alpha channel data.
By default, the global paintCompression property is set to "rle" in standalones and "png" in the development environment.The paintCompression of an image is one of the following: "png", "jpeg", "gif", "rle", or "pict". By default, the paintCompression property of a newly created image is set to "rle" if it was created with the create command or by using a paint tool. If the image was created with the import command, its paintCompression is set to the format of the imported picture file. For images, this property is read-only and cannot be set; you can set only the global paintCompression.

Hermann

Hi, Hermann and Bernd,
Looks like the paintcompression advice is working. I’ve added that as you advised, and it’s solved the scaling problem. So that’s good - thank you for your help.

It’s not something I expected, and I wasn’t aware that image formats changed (I was assuming that both the standalone and development environments were identical when it cam to running the code), so handy to know for the future.

Onwards! I can carry on doing what I want to do, and not spend time trying to track down this problem!

I can also get a revised build to a friend who has just got a 3D camera and has volunteered to give my application a spin.

You could report this as bug (or at least link there to here).
Because this means that the alphachannel creates a compression error and is by that causing the "offset" that Bernd means (that is, the imagedata is a few pixels shifted to right and longer than width*height determines).

I would have expected some crashes with such offset data ...