Offset-Fill Preview Hang on Linux

I just recently purchased a license for Lightburn for use on a computer (windows 10) and laptop (ubuntu 20.04) and I’m having an issue with preview window on linux that I’m not having with the windows version. When I turn off the offset fill, the preview window pops up normally and I can see the estimated time for both OS versions. For the offset fill on Windows 10, I get a message saying it is calculating paths for offset fill before showing the preview window. However, on Linux, I click the preview window and it just stops working. There is no dialogue saying it is calculating the path or indication that the software is working. I usually end up having to force quit LB to exit.

Please let me know if anyone else has run into this issue.

Which version do you have on each system? The newer releases improved the performance of the offset fill pretty dramatically, and added more update ticks for the progress bar, so if you have an older release on the Linux machine that could be part of it.

It’s also affected by the interval value - that controls how far apart the offsets are spaced, and if it’s very small on the Linux machine, and larger on the Windows machine, that would also explain the difference.

I checked and both versions are the same, V0.9.22. I did some more digging and I’m not sure I understand what I’m seeing. A design was created using LB involving a lot of calligraphy (text) that made the offset fill the faster option. Both Win10 and Ubuntu worked when the text was straight (0 deg rotation. However, when rotated to 90 deg. (to better accommodate the bed size), windows seems to handle it okay but linux still locks up. I did originally have a file issue (file was somehow corrupted that caused both machines to lock up) but after fixing that issue, the windows machine can cope but my linux laptop opening the same file locks up.

I am running the windows version on newer computer running Pentium j4115 w/ 6GB RAM and the laptop(linux) is running on an older laptop with i7 3520M w/ 8GB RAM.

That’s bizarre - the angle of the scan is completely irrelevant with offset fill - there is no “angle” because it’s following the contours of the shape, not just scanning across them, so it shouldn’t matter. It’s feasible that there’s a weird interaction somewhere in the job setup that’s getting confused, so I’ll have a look.

I thought the same thing. It’s just an image and direction should not alter the success rate of g-code generation. I haven’t gotten the chance to try it again as this project needed to get done before a solution could be found