CCSprite from SVG

[adamgeo]

Given the rumor of a bigger screen "iPad Pro" coming out, making a universal game under 100Mb is going to be almost impossible. Below is something I was messing with today. It creates a CCSprite from an SVG file using SVGKit.

eg: [SVGSprite spriteWithSVGFile:@"someSVGFilename" withSize:CGSizeMake(50.0f, 50.0f)];

SVGSprite Xcode Project

I was only playing around today so there's bound to be problems with my SVGSprite class but I was wondering if we could incorporate SVGKit into Cocos2d? I only skimmed the license but it appears to be similar to Cocos2d's.

One thing I've noticed with SVGKit, it might be fussy. An SVG exported from iDraw works fine but same file export from Affinity Designer and it doesn't work. It might be the AD exporter though. Its the biggest downfall of that app, it's quite bad and causes crashes a lot.

[birkemose]

Would definitely be an interesting feature, but I think such a thing should go into the -ext repo.
Also, I would add it as a category to CCSprite. We have WAY too many classes as it is : )

[Steffen_Itterheim]

I'd be most interested in performance and memory usage first. If it takes 5x longer to load an SVG than the sprite of the same size or memory usage spikes significantly during conversion this might not actually be that useful. I bet if using SVG at runtime in an app were without any noticeable drawbacks we'd have SVG support by now.

That's not to say everyone overlooked this or just kept the solutions to themselves. But does make me skeptical in how far the solution is viable. Could you make some tests with a couple SVG files, particularly those where the savings are signifcant (ie 4096x4096 image), then measure performance and memory usage behavior?

Also, I don't think the 100 MB limit is as important as it used to be. If anything you should stay far below that, otherwise you might as well go over it. Data plans haven't kept up with demand, so downloading 100 MB over the air is still signifcant if your data plan allows for 500 MB per month. Personally I never download apps over the air that are more than 10-20 MB, I can usually wait till / only look for apps while I'm in range of Wifi.

[adamgeo]

I haven't run any actual tests but I can tell you from observation that loading a large image is very slow, as in show an activity indicator slow. My level select background looks similar to a map of the world. Previously I had to export it from photoshop in slices to be displayed as tiles of sprites cause 1 big sprite stuttered while panning. When loading the svg it takes a while to load but being displayed it pans perfectly and the time indicator under the frame rate sits at 0.000.

The performance of such a big sprite was a bit surprising so there must be something else going on. I'll run some tests in morning, I'll have to look up how you were doing it, I think it's on your blog.

[adamgeo]

After a few tests I found SVGgh to be twice as fast as SVGKit and also supports a few more SVG features but memory is an issue. Seems CGImage in CoreGraphics is leaking. I might keeps playing with it for a while cause replacing a few background images totalling 40Mb with a few SVG files at less than 1Mb is probably worth the time.

Edit: CFRelease seems to have fixed the leaks. At first look this might be a good idea for background images. The amount the bundle size can be reduced it enough to not worry about a slight longer level loading time

[AndreasLoew]

If you already have a vector format from your artist this sounds like a good idea. I've been working with SVGs for quite some time and it can be quite tricky to work with them. Especially when exporting from Illustrator after converting images e.g. from Flash. We had to re-work many of the images because we got transparent outlines at the borders of the sub-shapes.

We've also spent quite some time after we found Illustrator embedding pixel data for gradients and such things.

Another problem is usually that not all of SVG is implemented in the renderers. From SVGgh: "Right now, it only implements the portions of the specification I needed or thought I might need."

You could also stay with pixel data - I see other options for saving memory:

• WEBP - it's like a mixture of PNG + JPG - you can set it to lossless or lossy if you want. The loader code for the format is easy to add and open source.
• 8 bit / indexed PNGs are also a great method - with PngQuant's compression you get quite impressive results.

I've created a sprite sheet with 2039x1743 and tested several of the formats:

png 8bit = 0.8 MB webp: quality=60 = 0.8 MB webp: quality=100 = 1,4 MB pvr-gz, RGBA4444 = 1.7MB pvr-gz, RGBA8888 = 2.1MB png 32bit = 2.9MB

So what I can see from here is that there is quite some room for optimization.

Another option would be only storing the graphics for the devices with the highest resolution and resize the images for the smaller devices on the fly. You could even save them in the temp folder for faster loading.

[nixarn]

I've been experimenting with webp quite a bit, but found the loading is just waaay to slow to make it a valid option. Any experience with this?

What we've done is we have a definition list for each spritesheet and and then run a script that runs the Texturepacker command line tool, so per spritesheet we set a few parameters, for example if possible we use RGB4444 and not dithered (as they compress better). I've been thinking one future solution for us would be to be able to specify per sprite if dithering should be enabled, that should help compression (but would be an annoying task to go through every sprite and specify dithering).

with a new device though, my hope is Apple would increaser the limit to at least 200mb, but I heard a rumor that Apple can't do that because Chinese operators wouldn't like that (no clue if there's merit to that).

[adamgeo]

Well, I started using SVG for my background images but with every new SVG file came more issue. I was using 3 different SVG decoders and choosing the one that worked best for each image. The speed started to become annoying as the SVG docs had to be stripped down for unsupported features and to try and speed it up. I ended up deleting all the SVG decoders and using PDF with the native decoder. Probably not as fast as png/pvr ect but a 1000% improvement on SVG and all features seem to work.

+(CCTexture*)textureFromPDF:(NSString*)string withSize:(CGSize)size {
    NSURL *url = [NSURL fileURLWithPath:[NSBundle.mainBundle pathForResource:string ofType:@"pdf"]];
    CGPDFDocumentRef document = CGPDFDocumentCreateWithURL((CFURLRef)url);
    UIGraphicsBeginImageContextWithOptions(size, false, 0);
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGContextTranslateCTM(context, 0.0, size.height);
    CGContextScaleCTM(context, 1.0, -1.0);
    CGPDFPageRef page = CGPDFDocumentGetPage(document, 1);
    CGContextConcatCTM(context, CGPDFPageGetDrawingTransform(page, kCGPDFBleedBox, CGRectMake(0, 0, size.width, size.height), 0, true));
    CGContextDrawPDFPage(context, page);
    CCTexture *texture = [[CCTexture alloc] initWithCGImage:[UIGraphicsGetImageFromCurrentImageContext() CGImage] contentScale:[[UIScreen mainScreen] scale]];
    return texture;
}

[siarsky]

Hi @adamgeo,

I am trying to use your very promising approach, but the PDF image does not scale up.

1. I've created a small pdf image onoff_body.pdf of size: 30x20 pixels (I am not allowed to attach a PDF, so please rename onoff_body.pdf.png into onoff_body.pdf).

2. I am trying to scale it up from 30x20 to 300x200, just to see, if the curve will stay smooth:

     CCNodeColor *background = [CCNodeColor nodeWithColor:[CCColor yellowColor]];
     [self addChild:background];
   
     CCTexture *texture = [self textureFromPDF:@"onoff_body" withSize:CGSizeMake(300.0f, 200.0f)]; 
     CCSprite *sprite = [CCSprite spriteWithSpriteFrame:[texture createSpriteFrame]];
     sprite.positionType = CCPositionTypeNormalized; 
     sprite.position = ccp(0.5f, 0.5f);
     sprite.anchorPoint = ccp(0.5f, 0.5f);
     [self addChild:sprite];

3. no luck with cocos2d 3.4.9, the image has always the same size:

   

Do you see, what am I doing not correctly?

Thanks siarsky

[adamgeo]

Have a look at https://github.com/mindbrix/UIImage-PDF and create the sprite form the CGImage. This worked out ok for very basic background images but PDFs cant really be used for any more than that.

[siarsky]

Thanks @adamgeo , I've looked into the code of UIImage-PDF and found a reference to an article explaining Apple PDF API Rendering PDF is easier than you thought, which shows how to scale up a PDF image. To put it into the same method as yours, it looks like:

    +(CCTexture*)textureFromPDF:(NSString*)string withSize:(CGSize)size {     
      UIGraphicsBeginImageContextWithOptions(size, false, 0);
      CGContextRef context = UIGraphicsGetCurrentContext();
      CGContextScaleCTM(context, 1.0, -1.0);
      CGContextTranslateCTM(context, 0.0, -size.height);
      NSURL *url = [NSURL fileURLWithPath:[NSBundle.mainBundle pathForResource:string ofType:@"pdf"]];
     CGPDFDocumentRef document = CGPDFDocumentCreateWithURL((CFURLRef)url);
     CGPDFPageRef page = CGPDFDocumentGetPage(document, 1);
     CGRect mediaRect = CGPDFPageGetBoxRect(page, kCGPDFCropBox);
     CGContextScaleCTM(context, size.width / mediaRect.size.width, size.height / mediaRect.size.height);
    CGContextTranslateCTM(context, -mediaRect.origin.x, -mediaRect.origin.y);
    CGContextDrawPDFPage(context, page);
    CCTexture *texture = [[CCTexture alloc] initWithCGImage;
    [UIGraphicsGetImageFromCurrentImageContext() CGImage] contentScale:[[UIScreen mainScreen] scale]];
    return texture;
  }

and indeed, it works:

I am curious, what you meant by "This worked out ok for very basic background images but PDFs cant really be used for any more than that."

Do you mean performance? Or you mean curves, which are not scaled up properly? Would you share your thoughts on this?

Thanks siarsky

[adamgeo]

I am curious, what you meant by "This worked out ok for very basic background images but PDFs cant really be used for any more than that."

A few reasons. Performance is pretty poor & memory usage is off the scale. There are many different ways to read PDFs and SVGs but none of them are perfect so it's a case of choosing which works best for the current situation