Combination of Phantom and not specifying algorithm causes 0 size png to be generated

[jpgough]

Firstly, thanks for an awesome grunt plugin. I had some issues today using this for the first time on Windows with Phantom. I was seeing that the css was generated fine, but the png had zero file size. My task looked like:

classes_sp : {
   src : '<%= css_src_path %>/classes/**/*.png',
   destImg : '<%= css_build_path %>/classes-sprite.png',
   destCSS : '<%= css_build_path %>/classes-sprite.css',
   'engine' : 'phantomjs'
},

By adding in the algorithm as binary-tree, rather than using the default, all of a sudden png files and css generated correctly. Admittedly the sprites were fairly large one 5Mb and one 70Mb (152 images) - which is ridiculous but I was just trying to get something working.

I think if it is related to the size an error stating that files were too large to sprite with the algorithm would be cool - a silent fail makes me a bit nervous to use this in production.

[twolfson]

Interesting, we might have reached an upper limit with the maximum height of the canvas. What is the average image height and width?

phantomjs is not optimized for PNG size and should be piped through grunt task to optimize it (although there is an open issue #46) which is on the same topic.

[jpgough]

Sorry for the crude example, but if you download the latest version of Dojo: http://download.dojotoolkit.org/release-1.9.1/dojo-release-1.9.1.zip then add in the build files below in you'll hopefully see how adding the algorithm ('algorithm': 'binary-tree') solves the problem:

package.json

{
  "name": "Problem",
  "version": "0.0.1",
  "description": "Issue 47",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "James Gough",
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-spritesmith": "~1.11.3",
    "grunt-sprite-generator": "0.0.2"
  }
}

Gruntfile.js

module.exports = function(grunt) {
    grunt
            .initConfig({
                pkg : grunt.file.readJSON('package.json'),

                sprite : {
                    dojo_sp : {
                        src : '**/*.png',
                        destImg : 'dojo-release-sprite.png',
                        destCSS : 'dojo-release-sprite.css',
                        'engine' : 'phantomjs'
                    }
                }
            });

    grunt.loadNpmTasks('grunt-spritesmith');

    grunt.registerTask('default', [ 'sprite' ]);
};

[twolfson]

No worries, any example is much better than no example =)

I will take a look at this by the end of the week.

[twolfson]

As a heads up, #46 has been resolved which means if you upgrade to the latest minor (1.12.0), then you will see a significant drop in file size.

I might take a look at your issue tonight but it is starting to get late.

[jpgough]

Thanks for the heads up, I'll give the minor version a go. No rush on looking at my issues, as there's a valid workaround - thanks for taking a look.

[twolfson]

I have taken a look but I am unable to reproduce. I am seeing an 83kB CSS and 176MB png. I tossed the work into a gist

https://gist.github.com/twolfson/7446850

[twolfson]

The newer version of spritesmith generates a 871kB png. It does take a lot longer to generate the file but that is due to a flaw in spritesmith; everything is buffer to memory instead of streamed out.

[jpgough]

What OS did you try it on? Is there anything else I can do on my side to try get a more reproducible example? If not I'm happy to close this as it could just be my dev machine.

[twolfson]

I am running Linux Mint 14. What are you running?

I am going to try pushing PhantomJS to its limits by adding more and more sprites.

[jpgough]

Sadly here I'm on Windows 7.

[twolfson]

Ah, cool. I can fire up a VM to see if I can reproduce.

[jpgough]

Thanks, sorry I meant to write it in the issue - user fail :).

[twolfson]

Interesting conclusion to the canvas case, it seems I run out of memory when I double up on the sprites

$ grunt sprite
Running "sprite:dojo_sp" (sprite) task
FATAL ERROR: JS Allocation failed - process out of memory

[twolfson]

Okay, I have successfully reproduced on Windows 7.

[twolfson]

Interstingly enough, you seem to have leapfrogged another Windows specific error. Writing out 200 of those sprites leads to an EINVAL error. That seems to be from trying to write too much of file synchronously to disk.