Playlab gallery

* capture screenshots of playlab solutions for sharing. Currently all this does is capture the state of the play area when the "Finish" button is pressed. (future options for refinement could include using the title screen text, the state of the play area after the "when run" blocks are finished, or giving the user multiple options for screenshots) This is done via canvg, which serializes and parses the <svg> element and renders it on canvas, then converts the canvas to png. See:
  * https://code.google.com/p/canvg/
  * https://github.com/sampumon/SVG.toDataURL
The libraries for this are all in a /canvg directory under /src, is this the right place to put these?
* I had to increase the maximum size of a POST request accepted by dashboard because these data url pngs are pretty large. (the size of the db column that holds these images is 16M, we should be fine there)
* show both "apps" and "art" on the main public gallery page
* do not show autosaved drawings in the public gallery
* add some constants to Game so we can use Game::ARTIST instead of 'turtle' ;)

TODO:
* ui test (can't really test the contents of the screenshot automatically, but can test that it doesn't break the Finish button)
* include the css for the svg elements in the screenshot (title screen among other things looks weird)
* split the personal gallery into "My Apps" and "My Art"
* pagination for private gallery
* classroom gallery
Hm.. in theory we could only send up the image if it’s going to be shared
or saved — however — all the sharing is done on client side (after the
request has been sent and response has been received from the server), so
it is not possible to tell if the solution will be shared at the time that
we are currently sending the image.

One possible solution is for the browser to lazily render/send the images
when it detects that sharing is possible. We could detect clicks on the
Facebook and twitter buttons, however, the one path that is impossible to
detect is using the URL that we show in the dialog.

On Tue, Oct 7, 2014 at 9:21 AM, cpirich <notifications@github.com> wrote:

> In blockly/src/studio/studio.js:
>
> > -                     });
> > +  document.getElementById('svgStudio').toDataURL("image/png", {
> > +    callback: function(pngDataUrl) {
> > +      Studio.feedbackImage = pngDataUrl;
> > +
> > +      BlocklyApps.report({
> > +        app: 'studio',
> > +        level: level.id,
> > +        result: Studio.result === BlocklyApps.ResultType.SUCCESS,
> > +        testResult: Studio.testResults,
> > +        program: encodeURIComponent(textBlocks),
> > +        image: encodeURIComponent(Studio.feedbackImage.split(',')[1]),
> > +        onComplete: Studio.onReportComplete
> > +      });
> > +    }
> > +  });
>
> I assume from this that we always want to generate and submit the PNG
> data? It looks like turtle behaves this way. But it may be a little
> inefficient (time spent constructing the PNG and data transferred to the
> server) unless we're planning to do something with all of these images.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/code-dot-org/code-dot-org/pull/120/files#r18530757>.
>