• Editor

  • Exporting gif crashes the spine

Hi there I am having really hard time to export gifs with nice quality. Exporting gifs makes spine crash at the middle of the progress.

I do get that Spine has 32 bit max compatibility and i cannot use a lot of heap space.

and my computer is actually far from being powerful .

So To better optimize export settings for my gifs I want to know what settings are the most consuming for spine?

like better to crop gifs or leave original size?
or does scaling actually makes it easy to export?
does mesh attachments makes it harder to export?
or maybe attachment count ?
what about Quality or FPS . how they affect

Related Discussions
...

What version are you using? 3.7 has much better GIF exports than previous versions. There are many new settings and the GIF quality is as good as the GIF format allows.

Note the Spine GIF export's goal is not to make the smallest GIF file size, instead the priority is to make the highest quality GIF and a small file size is secondary to that. You can use other tools to reduce the file size of the GIF that Spine exports, but the quality will suffer (sometimes severely).

Unless you are exporting extremely high resolutions, there should not be any memory or heap size problems. Spine also doesn't require a powerful computer. Cropping and scaling can reduce the resolution, so GIF export will be faster and use less memory. What is the resolution of a GIF that fails to export?

FPS controls how many frames are output, so of course has a big impact on the export speed and file size.

Quality of 10 or 9 can make GIF export very slow. 8 is a reasonable trade off for speed vs quality. Compared to 10, a quality of 3 is 5% lower quality but about 8x faster. Quality of 2 or 1 turns off more features and the file size can be a bit larger, but export is as fast as possible.

The number of colors mostly reduces file size but export speed is also a bit faster with fewer colors.

Your skeletons, how many meshes they use, etc doesn't really affect export speed.

Spine should never crash. Please post your spine.log file (the forum will redact it) after a crash:

Windows: <user home folder>\Spine\spine.log
Mac: <user home folder>/Library/Application Support/Spine/spine.log
Linux: <user home folder>/.spine/spine.log

I do know what do all these settings I just dont know which one impacts more on crashing. maybe cropping actually eats more memory then just leave it original size.

well then I will share with you my project that crashes instantly cropped with low quality and scaled 20% so final result is 800x800

I think you might have better PC so try to export at 100 scale .

my log is empty

Spine Launcher 3.8.12
Esoteric Software LLC (C) 2013-2019 | http://esotericsoftware.com
Windows 10 Home x86 10.0
Up to date: Spine 3.8.25-beta
Spine 3.8.25-beta Professional
NVIDIA Corporation, GeForce GT 750M/PCIe/SSE2, 4.5.0 NVIDIA 381.94
Started.
OpenAL 1.1, Default audio device

check support email 🙂

Thanks for sending the project. I've exported the GIF at 100% scale with no problem. It took a while, maybe 4 minutes to export 160 frames that are 2811 x 3206 each (which is huge!). The GIF is 80.82MB! I've emailed it to you.

The log is replaced each time Spine runs. Did you capture the log after Spine crashed?

Spine should never crash, no matter which settings you use. I hope you can cause a crash, then show an error in the log. If not, are there any hs_err_pid.log files created in the Spine installation directory? Do you see the "Sorry, Spine has crashed dialog" or does the Spine window just disappear? It could be that your graphics hardware or driver is unable to handle exporting and is crashing Spine. Do you have the latest graphics drivers for your graphics hardware?

FWIW, on the technical side, for export Spine renders just like it does in the editor, but to a buffer instead of to the screen. The buffer is in graphics memory and next is transferred to RAM, then to disk. The buffer is sized to the output image size, so scaling down your export will require a smaller buffer and therefore less graphics memory and RAM. If you don't have any problems with rendering your skeleton in Spine, exporting should be even less intensive than that, theoretically. Spine asks the graphics driver how large of a buffer it can create, but many drivers lie and just give a huge number, then they crash hard when Spine tries to allocate a large buffer. Unfortunately there is nothing Spine can do in that situation. However, I don't think this is your problem because if it were, you would be able to export successfully at small scales. Eg, a scale of 10% would only be about 281 x 321, which should be no problem at all.

Thank you very much for the time you spend. for explanation and GIF 😃

I reproduced crash again and this time, checked the log without opening spine and again nothing is there. just some data.

no dialog is being shown when it crashes. I just return after some time and spine is closed 😃 I can see before crash in task manager it is shown as not responding.

I dont have problems in the editor . maybe when images are being loaded 10 fps but after that all is good.

I checked hs_err_pid files I had 2 but very old.

I think I can have some new updates for graphic card. will update them right now. hope that will help.

Thanks for the video you emailed showing the crash. Something very terrible is happening at a low level to make Spine crash without showing the "Sorry, oopsie!" dialog. Maybe there is something in Windows Event Viewer? I hope updating the graphics driver helps!

Faulting application name: Spine.exe, version: 3.8.12.0, time stamp: 0x5c1400ab
Faulting module name: nvoglv32.DLL, version: 22.21.13.8194, time stamp: 0x58fd394f
Exception code: 0xc0000409
Fault offset: 0x00d920cb
Faulting process id: 0x1490
Faulting application start time: 0x01d5260f2e785bc8
Faulting application path: C:\Program Files (x86)\Spine\Spine.exe
Faulting module path: C:\WINDOWS\SYSTEM32\nvoglv32.DLL
Report Id: 1ea26379-88cf-4b8c-a842-c6d6165987ed
Faulting package full name: 
Faulting package-relative application ID: 
Unable to recover from a kernel exception. The application must close.


Error code: 3 (subcode 7)
 (pid=5264 tid=15120 spine.exe 32bit)

Visit http://www.nvidia.com/page/support.html for more information.

Ouch, that tells us that the graphic driver is actually failing hard. The driver you are using is from 2017. Maybe you could try updating your NVIDIA driver?

a year later

upgraded the driver. I think all is good now 😃 sorry for bothering you

Sorry guys for bringing this up. but this crash actually never gone and I am struggling exporting high quality gifs. I know for sure that it is my Graphic card and update actually seemed to help but no.

however recently I bought a new PC super High end with the latest graphic card and drivers sometimes it crashes again forcing me to restart or play with options to finally export it. I think this one is little different issue since it always freezes at 0 frame when exporting. while the previous crashes on older pc were freezing at some random frame.

here is the log from event viewer

Log Name:      Application
Source:        Application Hang
Date:          06/09/20 20:14:50
Event ID:      1002
Task Category: (101)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DESKTOP-IK31OSC
Description:
The program Spine.exe version 3.8.82.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
 Process ID: 1200
 Start Time: 01d63e89a6a17836
 Termination Time: 4294967295
 Application Path: C:\Program Files (x86)\Spine\Spine.exe
 Report Id: 5a6e98fa-ea3e-4747-8517-c0e1319bce47
 Faulting package full name: 
 Faulting package-relative application ID: 
 Hang type: Top level window is idle

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Hang" />
    <EventID Qualifiers="0">1002</EventID>
    <Level>2</Level>
    <Task>101</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2020-06-09T18:14:50.025222900Z" />
    <EventRecordID>3867</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DESKTOP-IK31OSC</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Spine.exe</Data>
    <Data>3.8.82.0</Data>
    <Data>1200</Data>
    <Data>01d63e89a6a17836</Data>
    <Data>4294967295</Data>
    <Data>C:\Program Files (x86)\Spine\Spine.exe</Data>
    <Data>5a6e98fa-ea3e-4747-8517-c0e1319bce47</Data>
    <Data>
    </Data>
    <Data>
    </Data>
    <Data>Top level window is idle</Data>
    <Binary>54006F00700020006C006500760065006C002000770069006E0064006F0077002000690073002000690064006C00650000000000</Binary>
  </EventData>
</Event>

Spine actually does not close, it just freezes. for that particular project after turning Linear Off exports quick. will be back here if understand how to reproduce it on any machine.

Apparently Windows has a timeout and will terminate an app that doesn't respond for too long.

Turning off linear prevents it from freezing and the export completes quickly instead? :wounded: The difference is very small, textures just get a different texture filter, everything else is the same. It really shouldn't make a difference. Maybe it's something about the GPU drivers?

But Windows doesn't terminate Spine, it just hangs there. and the URL you posted is about delaying Task manager dialog appearance. Doesnt even show as Not responding when I open Task Manager

I updated my drivers recently, and it is not Linear I believe too. since now it doesn't work either.

Maybe it fails when tries to get access from windows to save the file? ah no I see the file with one frame half rendered.
I can easily export huge projects with highest qualities... but... some projects are killing me 😃

now I just upgraded spine back to latest and finally exported... was using 3.8.59

So you're all good running the latest (3.8.95)?