Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

TexturePacker CLI is very slow even with "Fast" option on

zurrutik@yahoo.es

Hi all,

My toolchain includes a command to generate atlases by using Spine Command Line Interface, but unfortunately it's very impractical to use since it runs terribly slow, even with the "Fast" option turned on... On my machine I get the following timings:

Spine -i data -o output -n game -p ..........\utils\texturePack.json

Fast mode( 12 seconds )

Spine Launcher 3.6.34
Windows 10 Home x86 6.2
Java 1.7.0_80 Esoteric Software
32-bit Server VM
Spine 3.6.53 Essential
Licensed to: ********************
Pack: game
data
Packing................
Packing................
Writing 2048x2048: output\game.png
Writing 2048x2048: output\game2.png

Non-fast mode(11.5 seconds)

NOTE: you can tell this is the non-fast mode because it manages to create one 2048x2048 and one 1024x2048 instead of two 2048x2048 like above

Spine Launcher 3.6.34
Windows 10 Home x86 6.2
Java 1.7.0_80 Esoteric Software
32-bit Server VM
Spine 3.6.53 Essential
Licensed to: *************************
Pack: game
data
Packing................
Packing.........
Writing 2048x2048: output\game.png
Writing 1024x2048: output\game2.png
Complete.

Please find attached the texturePack.json file with all the options that I used for the tests( obviously "fast": false or "fast": true does change in order to use/not use the fast mode )

texturePack.json

Why the difference in timings is so negligible? It'd be very helpful that the "Fast" mode would be actually faster than the normal mode, specially if running this command is part of a toolchain( in my case I run it as a pre build script ).

Could you please give me a workaround for this so that the TexturePacker is really fast even though the resulting atlas(es) are not as compact?

Cheers,

Javier

zurrutik@yahoo.es

Nate

How many images are you packing?

As for settings that would make it faster, try setting the min page size to same as the max page size. Requiring power of two page sizes speeds it up too (you have it set but others finding this might not). Also try turning off both alias and limit memory. If it is still slow we can look into it further.

zurrutik@yahoo.es

Hi,

Nate, thanks for your quick response. I am packing only 54 images, please have a look at my .atlas file( See gameAtlas.txt attached ) so that you can see the amount of files that I am packing as well as their respective sizes

Unfortunately the suggested changes dont make things too much better, only a tiny little bit. I am using PowerShell instead of regular ms-dos so that I can use "Measure-Command" to time the executions

Old texture pack options( See texturePack.old.json attached )

PS > Measure-Command{ Spine -i data -o output -n game -p ../../../../../utils/texturePack.old.json }

Dec 07, 2018 4:06:42 PM java.util.prefs.WindowsPreferences openKey
WARNING: Could not open windows registry node Software\JavaSoft\Prefs\com\esotericsoftware\spine\editor\launcher at root 0x80000002. Windows RegOpenKey(...) returned error code 5.
java.lang.SecurityException: Could not open windows registry node Software\JavaSoft\Prefs\com\esotericsoftware\spine\editor\launcher at root 0x80000002: Access denied
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:513)
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:480)
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:466)
at java.util.prefs.WindowsPreferences.putSpi(WindowsPreferences.java:612)
at java.util.prefs.AbstractPreferences.put(AbstractPreferences.java:251)
at tzax.V.a(SourceFile:161)
at tzax.V.a(SourceFile:143)
at tzax.s.run(SourceFile:1032)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745)
at java.awt.EventQueue.access$300(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:706)
at java.awt.EventQueue$3.run(EventQueue.java:704)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:715)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Days : 0
Hours : 0
Minutes : 0
Seconds : 12
Milliseconds : 44
Ticks : 120445851
TotalDays : 0.000139404920138889
TotalHours : 0.00334571808333333
TotalMinutes : 0.200743085
TotalSeconds : 12.0445851
TotalMilliseconds : 12044.5851

New texture pack options with all the recommended changes( See texturePack.json attached )

PS > Measure-Command{ Spine -i data -o output -n game -p ../../../../../utils/texturePack.json }

Dec 07, 2018 4:10:58 PM java.util.prefs.WindowsPreferences openKey
WARNING: Could not open windows registry node Software\JavaSoft\Prefs\com\esotericsoftware\spine\editor\launcher at root 0x80000002. Windows RegOpenKey(...) returned error code 5.
java.lang.SecurityException: Could not open windows registry node Software\JavaSoft\Prefs\com\esotericsoftware\spine\editor\launcher at root 0x80000002: Access denied
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:513)
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:480)
at java.util.prefs.WindowsPreferences.openKey(WindowsPreferences.java:466)
at java.util.prefs.WindowsPreferences.putSpi(WindowsPreferences.java:612)
at java.util.prefs.AbstractPreferences.put(AbstractPreferences.java:251)
at tzax.V.a(SourceFile:161)
at tzax.V.a(SourceFile:143)
at tzax.s.run(SourceFile:1032)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745)
at java.awt.EventQueue.access$300(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:706)
at java.awt.EventQueue$3.run(EventQueue.java:704)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:715)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Days : 0
Hours : 0
Minutes : 0
Seconds : 10
Milliseconds : 669
Ticks : 106691842
TotalDays : 0.000123485928240741
TotalHours : 0.00296366227777778
TotalMinutes : 0.177819736666667
TotalSeconds : 10.6691842
TotalMilliseconds : 10669.1842

( By the way, ignore the warnings, both commands execute successfully, and I read in a Java forum that they can be safely ignored )

As you can see the saving are not great... I remember using a very naïve algorithm to pack textures that took about 2 seconds tops, I wonder if this one takes so long because Spine needs to boot up fully, authenticate, check for updates etc etc and that is causing the delay?

Is it possible to run Spine as a service so that I can connect to a port and send e.g. "-i data -o output -n game -p ../../../../../utils/texturePack.json" in order to save time?

Alternatively, do you guys have an API like Maja so that we can create a custom exporter for Spine? Provide access to the Scene elements and images etc etc?

Cheers,

Javier

Nate

If you download and reinstall Spine, those warnings should go away.

Spine doesn't provide a service for CLI processing, sorry. Depending on the command line parameters, Spine will avoid doing all of its normal initialization, which allows it to run on headless machines. If you are running it solely for texture packing, there should not be much overhead. Spine also does not yet have a scripting API to allow the application to be automated.

The texture packer in Spine is the texture packer I contributed to libgdx, which is FOSS:
https://github.com/libgdx/libgdx/wiki/Texture-packer
https://github.com/libgdx/libgdx/blob/master/extensions/gdx-tools/src/com/badlogic/gdx/tools/texturepacker/TexturePacker.java
As described in that first link, you can grab the texture packer from the libgdx nightly build and run the JAR file without Spine being involved.

BTW, the TexturePacker class has a processIfModified method which avoids packing if the output files have a timestamp newer than the input files. We should expose this as a setting in Spine. Otherwise if you want to use that, you can write a couple lines of Java to do it. Let me know if you'd like assistance doing that.

It would be most helpful if you could send your 54 images so we can run the texture packer ourselves and debug why it is slow for your particular input. Bin packing involves some brute force and can easily be made faster by simply doing a poor job. Spine's packer doesn't make packing speed a priority, instead attempting to pack as small as possible in a reasonable amount of time. However, if fast is used, the packer should be fast and if it isn't we'd like to fix that.

zurrutik@yahoo.es

Yes, actually the standalone version is much faster, thanks a lot for letting me know:

Measure-Command{java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker data output game texturePack.optimized.json}
...
TotalMilliseconds : 5006.931

Measure-Command{java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker data output game texturePack.json}

...
TotalMilliseconds : 6269.625

Measure-Command{Spine -i data -o output -n game -p texturePack.optimized.json}
...
TotalMilliseconds : 13518.075

I suppose the fast algorithm maybe could be improved, but 5 secs is alright but as you can see the overhead of using it via Spine command line is quite a bit, and that overhead unfortunately happens as well when we export the skeletons:

Measure-Command{ Spine -i game.spine -o output -e skeletonExport.json }

...
TotalMilliseconds : 9204.534

Would it be possible to get a standalone version of the exporter as well?

Cheers,

Nate

I'm afraid the Spine export is built into the application quite deeply. I'm surprised it is taking so long, both to run Spine and to run the packer with fast on. My offer still stands, if you can email the images you are packing then we can look into why it is slow when fast is used. contact@esotericsoftware.com We'll keep your files confidential. If you are very worried, you could black at the images (don't need alpha since you strip whitespace), as long as that doesn't change the times.

zurrutik@yahoo.es

Well now that you mention it, I did modify the original images to send them to you and guess what, it takes a lot less time:

Measure-Command{java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker dataModified output game texturePack.optimized.json}

...
TotalMilliseconds : 3552.8989

This to me is very surprising because why would the texture packer performance be affected by the content of the images?Anyway, you wrote the TexturePacker so you probably know why 🙂

Sure, I will send both the original and the modified version of the images to the email provided in case you can make improvements to the Fast option, but to be honest the only thing that would make things better for me would be the possibility of somehow leave an instance of Spine waiting on a port then be able to send both export and texture packer commands to it( and then if Spine executes each command in a different thread that would be epic!! ).

Is this a feature that people want and maybe will be implemented soon?? Otherwise I suppose I will have to be very methodic and every time I modify something I will have to remember to not only Save but also Export and call TexturePacker from the Spine menu...

Cheers,

Nate

Thanks, we tried the files. For us they packed in less than 1 second, both the modified and original images. I'm not sure why it would take 3x+ longer for you!

The Spine launcher version 3.7.78 (not released yet) has a lot faster startup when using the CLI.