David Heffernan

Who are you hoping does this? i.e. who is "you" in your question?

Nah, that's not going be to the cause of the error reported in the original post. Hard to say what is the problem though without knowing the other side of the interface. How can we know how the function is declared in labview? My expectation is that the real issue is a mismatch at the binary interface layer.

The thing is, both resizing and compression will change the image and only you can judge which you prefer. It depends on what you are trying to do with these images, what sort of images they are. In my view you need to engage with that side of things first, not in a coding setting, to work out precisely what transformation you want. Then implementing it in code should be simple.

Do you want to resize the image or increase the compression? And which framework, vcl or fmx? And if you want to resize, what resampling do you want to use?

It's also pointless to use SetLength in this code because you then throw that array away and replace with a new one.

Isn't that what Ord() is for?

That returns a UTF-8 encoded byte array which you can copy into your record. Are you familiar with TEncoding, it's a somewhat import tool for text encodings?

TEncoding.UTF8.GetBytes

TEncoding.UTF8.GetBytes You don't need to use AnsiString.

You shouldn't. It makes absolutely no sense.

If you really need to do this then you probably need to switch to a different tool, or use an old version of Delphi. Modern Delphi just produces huge executables. Or you could just decide not to worry about a few MBs.

Don't rely on whether or not a function is inlined in order for the code to work. After all, it might not be possible to inline it.

Maybe worth digging a bit deeper. There seem to be a good few discussions on SO. I'm probably talking nonsense about a race, but I also bet that wait + GOR isn't right.

Doesn't the original code have a race?

Answer likely to be found in the source code

It is removed from the stack when the method returns. I don't think you've got to the bottom of the issue yet.

It's a fixed length array, so it's a value type. Which means that when you pass it as a value argument, it travels via the stack. If it were a dynamic array then it would be passed as a pointer to the first element. Not that strange really. Changing from 32 to 64 bit is significant. You've been getting lucky up until now. All that copying of huge objects must cost a lot of time and make for inefficient memory usage. Mindset is important here. It's very rare that you will find compiler bugs (even with the Delphi compiler!) So always suspect your own code first.

@marcocir start from the assumption that the compiler is correct and that your code is faulty. That's far and away the most likely explanation. With that mindset, read Arnaud's answer again.

Are the collections in mORMot generic? Because if not then there's no way to make a fair comparison.

Whatever you do, don't use floating point arithmetic!

@David Schwartz Are you familiar with how C# implements out params. Why can we have that?

It would be nice if that documentation was accurate, but it's not. You will have no problems passing a non-nil instance into that function using an out param. You'll find, at least for non-managed types, that out and var parameters behave identically.

Back in the day 16 bit Windows GDI used 16 bit coordinates, so the issue could very easily be a hang over from code written in that era. Either in the Windows API or in the VCL.

Your problem is with this memcache class. That's what you need to fix. Shouldn't be using AnsiString.

Only you know what your memcache is doing, but I'd guess that it uses an 8 bit encoding, perhaps AnsiString. You need to understand a problem before trying to solve it.