LaserGRBL silently fails to import certain raster images at higher resolution about lasergrbl HOT 6 OPEN

Processing take 2 seconds on my PC to generate gcode.

from lasergrbl.

I was able to generate up to 2000x400 that is 40 times bigger (it takes about a minute)

from lasergrbl.

It might be worth noting that I'm on a 32-bit platform (WINE, specifically)

Yes, the fact that it is 32bit imposes limits on the process especially on memory usage

from lasergrbl.

You're saying that on 64-bit Windows it's working fine?

I can see about reconfiguring WINE, I didn't realize you had a 64-bit release.

from lasergrbl.

...where is your 64-bit release? The installer executable is 32-bit and appears to install 32-bit binaries:

LaserGRBL.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows, 3 sections

FWIW, installing the 32-bit release in a 64-bit WINE environment does mostly-kinda-work but does not change the behavior when attempting to import raster images with many lines.

Would it be possible to at least get an error message in response to whatever resource allocation failure is happening under the hood? Claiming success and silently creating a size-zero project is confusing, particularly since some other bug causes it to not always update the display when this happens.

Edited to add: Okay, using a 64-bit WINE environment running LaserGRBL in 32-bit mode does appear to increase the maximum image that can be imported, but evidently not to the same extent as on your actual 64-bit Windows machine. I can import at 4 lines/mm. It looks like LaserGRBL hits a maximum virtual memory size of 2.7 GiB during the import process before shrinking back to a resident size of 230 MiB. Presumably that was just enough to bump over the 2 GiB limitation in 32-bit Windows' memory layout. Doubling the resolution to 8 lines/mm sounds like it works for you but does not work here.

from lasergrbl.

Executable is a Microsoft .NET Framework executable built for both x86/x64.
The OS decide if to run it in x86 or x64 environment.

I believe you see PE32 executable because the "bootloader" is always 32bit (unless the executable can't run under win32 at all) but the OS switch to x64 just after loading the initial session of the exe.

Keep in mind that .NET is an interpretated language, so it is not rally an executable with compiled code, but an assembly with an intermediate language on it, that the interpreter translate "on the fly" to machine code.

https://en.wikipedia.org/wiki/Common_Intermediate_Language

Actually LaserGRBL trap all its own unexpected exception to a cute form that show all the details, including stack-frame and loaded assembly. If it does not open it should be because this crash is so low-level that my code cannot see it.
I suggest you to get a look in wine/mono logs.

Here, attacched, a version build to be x64 only. Hope this can help your system to load it as x64.
Simply replace the exe

LaserGRBL.zip

from lasergrbl.