scastie

scastie copied to clipboard

/cc @stanch

reftree is a really nice way to visualize data structures. it would be nice to use it in scastie.

https://github.com/scalacenter/scastie/commit/85de6200e854574ea0986bae75a23be4b8c00841 adds graphviz to the docker container running the sbt instances. I only need to redeploy this change.

The scrimage demo (https://github.com/scalacenter/scastie/blob/master/demo/scrimage.scala#L1) shows how we can render an image in the jvm and send it back to the browser.

@stanch Done.

https://scastie.scala-lang.org/MasseGuillaume/fNDpQ9AgRbKA4KEvP3NaeQ/1

I added a image(path: String) to the api to display images from the server using base64 encoding.

For some reason, animations throw an Exception.

Very cool! Let me see if I can run the docker container and dig around it to find the issue with animations. I guess it’s also time for me to stop relying on Consolas...

take a look at https://github.com/scalacenter/scastie/blob/master/CONTRIBUTING.md#contributing

cd docker
<edit Dockerfile>
docker build -t scalacenter/scastie-docker-sbt:0.0.14 .

<bump docker version>
https://github.com/scalacenter/scastie/blob/master/build.sbt#L122

sbt
> sbtRunner/reStart  or sbtRunner/docker then docker run --network=host scalacenter/scastie-sbt-runner:0.16.0
> ~server/reStart

So after about 2 hours of debugging I finally traced it to a problem with text rendering. Converting SVG to BufferedImage (which is what the animations do via Apache Batik), without text — fine; with text — crashes.

Searching for “java alpine linux text rendering” lead me into this thread: https://github.com/docker-library/openjdk/issues/73#issuecomment-207816929. With -Dsun.java2d.debugfonts=true, here is what I got:

...
Apr 26, 2017 11:40:02 PM sun.font.SunFontManager findFont2D
INFO: Load fonts looking for:Lucida Sans Regular
java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1333)
	at sun.font.SunFontManager.loadFonts(SunFontManager.java:3298)
	at sun.awt.X11FontManager.loadFonts(X11FontManager.java:460)
	at sun.font.SunFontManager.findFont2D(SunFontManager.java:2348)
	at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220)
	at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100)
	at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927)
	at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302)
	at sun.awt.X11FontManager.loadFonts(X11FontManager.java:460)
	at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429)
	at sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766)
	at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225)
	at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252)
	at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94)
	at org.apache.batik.bridge.DefaultFontFamilyResolver.<clinit>(DefaultFontFamilyResolver.java:87)
...

I am happy to say that running apk add --update ttf-dejavu like suggested in the linked comment completely solved the problem. Additionally for pretty rendering I would be grateful if you could add the Source Code Pro font, which is the new default font in reftree, replacing proprietary Consolas.

I will send a PR with these changes.

Diagram: https://scastie.scala-lang.org/zzQ4rnCFRVKQUqQjM7n0AA

Animation: https://scastie.scala-lang.org/8oZtpMStRduxM2PfphZsfA

The animation shows as a static image. ImageIO.read does no read the gif: https://github.com/scalacenter/scastie/blob/master/runtime-scala/jvm/src/main/scala/com.olegych.scastie.api.runtime/Runtime.scala#L17 This could solve the issue: http://elliot.kroo.net/software/java/GifSequenceWriter/

also

You can add additional bogus fields to the data url to force replaying of the animated gif: url(data:image/gif;bogus:ABCDEF;base64,R0lGODlhA...); see http://stackoverflow.com/a/12228790/449071

This could solve the issue: http://elliot.kroo.net/software/java/GifSequenceWriter/

Not sure I understand, doesn’t the problem have to do with the reader? Also scrimage already has a class like that, I am using it to generate those gifs ;)

ImageIO does not read the animation part of the gif.

basically what we need is to read the gif data and convert it to base64 so it can be sent to the client.

Actually I am not sure if ImageIO is really needed :) base64 encoding can be done on the file itself (and the MIME type can be derived from the file extension). Image width can be left unspecified or set to some percentage of the screen... (or it can be calculated with ImageIO just like it is now, that should work for animations as well).

Since this is closed, should I open a new issue for correct rendering of non-PNG images?

Edit: I meant animated images, or anything else not fully supported by ImageIO.

Oh indeed this was still pending. Reopening this issue.