In a 32 bit build on windows, attempting to open a large image generates this error
(Nothing to do with customer’s Norwegian language setting)
A smaller version loads fine.
I assume its running out of memory… it works fine on a Mac.
Is there a way to determine the size of an image on disc before attempting to load it?
(My first step is to load it into a GMImageMBS object to see if it needs to be rotated
gorig = new GMImageMBS(f) //where f is a valid folderitem
)
Yes, you need to read the image meta data. I don’t know what services are available on Windows for doing this. For instance on the Mac you can load the image file via CoreGraphics and extract just the meta data, without actually loading the image pixels.
In theory, a 32 bit windows EXE should be able to use about 4GB of memory, but in practice it’s far less (often as little as 1GB).
Any reason you aren’t compiling for 64 bit windows?
A 32bit build works on all Windows machines.
My understanding is that GraphicsMagick is designed to operate on images larger than the memory available.
Have you tried adjusting GMImageMBS.cacheThreshold?
At this point I can say that Opening the test image fails in GMImageMBS
But opening it as a memoryblock and then using PictureFromData() works, albeit slow
I haven’t encountered cachethreshold yet, but I will look into it.
I also just read about GMImageMBS being 8 bit where GM16ImageMBS is 16bit
Most examples are GMImageMBS, I wonder if that is significant?
If it’s working via a memoryblock it could mean there is a bug in the plugin. Probably best to ping Christian.
The GM16 version is for 16 bits per pixel images rather than 8. If you use that version then everything will use more memory and be slower.
True, however, it’s important to note that 32 bit EXEs run on 32 and 64 bit windows; 64 bit EXE will only run on 64 bit windows. (Just in case you were under the mistaken impression that 64 bit windows can’t run 32 bit EXEs?)
But the market share of 32 bit windows installations is tiny, likely to be under 1% - and I would guess there’s a significant overlap between (People using 32 bit windows installations) and (people who have no money or intent of buying software).
I’m not. 32bit builds work on all of them. 64bit might not. 
The 64bit builds also have a much bigger footprint, and rely on the DLL hell that came in after Xojo 2015.
On Windows (only) I am currently resisting moving from Xojo 2015, to avoid the change to DirectX (because it breaks a lot of my apps functionality - I restest each year and fail each time) , the Microsoft runtime DLLs, API2…
Jeff sent me a picture for testing.
It’s 10 MB as JPEG; but 607 MB in memory.
and please notice that rotate needs old and new picture in memory, so needs another 607 MB.
And if you call CopyPicture, you get a copy as Xojo picture, which may take 607 MB. Then you add mask and get 607 MB for that again.
Eventually you run out of address space in 32-bit.
I used to worry about app size a lot, but it’s been a while since I’ve had anyone mention or even seem to care about that.
What DLL hell do you mean? The thing that bugs me about 64 bit EXEs is that only some of the DLLs go in the Libs folder, but some have to be next to the EXE. Is that what you mean?
The nice thing about 64 bit apps is that they are (generally) so much more forgiving - as Christian points out, 32 bit apps really can get easily overwhelmed, whereas a 64 bit app is a lot harder to overwhelm.
So as to your original comment:
It might be more accurate these days to say:
“A 32 bit app launches on more machines, but a 64 bit app works correctly more often” ?
DLL: The business about ms-api-crt.xxx… &c needing to be included.
And the 20Mb DLL added when Xojo switched to Text from String.
I just did an analysis on recent sales.
Although it surprised me, the registrations from 32bit devices does back up your numbers … around 1%
Thats WAY down from the same time a year ago.
So maybe I’ll give 64bit another try soon… (last time I tested 64bit builds , the graphics side of things still didn’t work properly…refreshes/invalidates just didn’t work properly, and transparency had all changed)
Update: tried a 64 bit build.
It’s painfully slow, and invalidate doesn’t trigger a repaint reliably
(API1, not 2…)
If you are going from a GDI+ version of Xojo to a Direct2D version of Xojo then there is a very high chance you won’t get an acceptable result by just opening your project and compiling it. For example, having the Transparent property set will slow things down.
you won’t get an acceptable result by just opening your project and compiling it.
This is sadly true.
But DirectX was developed for gaming, for goodness sake…
And the move to 64bit was claimed to be faster , as I recall.
You would expect it to fly.