2020 International Conference on Computational Science and Computational Intelligence (CSCI) Cross-Compiled Plotting with SwiftVis2 Nicholas J. Smoker and Mark C. Lewis Department of Computer Science, Trinity University, San Antonio, Texas, United States Abstract— This paper explores adding support to SwiftVis2, Indeed, even many visualization libraries that are not JVM a plotting library written in Scala, for compiling and running based, such as PLplot and ggplot2, are cross-platform. Less across the JVM, web browsers, and native compiled code. common are cross-compile target visualization libraries. To We find that it is possible to use a single core library written elaborate, Scala allows code to be compiled to multiple in standard Scala across these various compile targets with targets; the most common is the JVM, but JavaScript and little additional code. The quality of the output and ability native machine language are also supported, using Scala.js to handle large datasets varies significantly for different and Scala Native respectively. A cross-compile target library implementations. The use of Scala, or other languages has notable advantages: programmers using SwiftVis2 can that have compilers targeting multiple platforms, makes it use the same code to produce plots for native and web possible to easily target many platforms with relatively little applications with only very minor modifications. To make effort. SwiftVis2 a cross-compile target library, we have made changes to allow the backend to be entirely platform agnostic Keywords: Data Visualization, Scala, Cross-Compile (by this, we mean that our backend code has no dependencies on libraries specific to any target). This was enabled by 1. Background and Introduction an early design decision to have the actual drawing per- Visualization of data through plots has a long history that formed through calls to an abstract type we refer to as goes back nearly two thousand years [1]. In the modern a Renderer. The core implementation includes its own era, this work is done with computers and software and as Renderer that outputs SVG graphics as a String. Writing the amount of data and its usages have grown, the need separate Renderer implementations for each compile tar- to visualize it has grown as well. Having the same tools get allows the same core logic to be used for plotting on across multiple platforms for this work can be beneficial each of them. We are currently able to reproduce plots that so that users don’t have to learn different tools for every utilize the full capabilities of SwiftVis2 on every platform, platform that they work with. In the past, this meant that though the implementation on the Native platform lags the tools had to work on various operating systems. A variety others, in large part because that is the least mature backend of tools have been published for just that purpose in various for the Scala compiler. disciplines [2], [3], [4]. Today it can imply working on web browsers and mobile environments as well. Virtual machines, 1.1 JVM like the JVM and .NET, have provided a certain level of OS The original version of SwiftVis2 is described in [7] independence for many years [5], but often have significant and was written to work with SVG and JavaFX on the memory and startup overhead. Just working on the web also JVM. Shortly after the publication of that paper, a second makes many tools OS independent, but runs into limitations Renderer for the JVM using Swing was added to compare of the JavaScript sandbox on browsers. performance and output quality. These comparisons are Plotting tools as a category encompass both user-level discussed in this paper in section 3. The decision to make tools with graphical interfaces for manipulating settings as a Swing Renderer was motivated in large part because well as libraries used with programming languages. In this of the poor performance of the JavaFX based version, but paper, we concern ourselves with the latter category and it is made even more significant by the decision to ex- look at how we can do plotting across multiple compile clude JavaFX from the standard JRE/JDK installs for many targets using a library written in a single language. The distributions, including OpenJDK, beginning with Java 11. goal is for the majority of the functional code to be written This also motivated us to separate the JVM code into three in a platform and compile-target independent manner such sub-projects. One handles JVM-specific functionality that that small additions can be added for each compile-target to is independent of both JavaFX and Swing. This primarily provide functionality there. includes code that uses the java.io package for file SwiftVis2 [6] is a plotting library written in Scala, which, manipulation. There are two other sub-projects that include up to this point, has used JavaFX or Swing for rendering. the specific Renderers for JavaFX and Swing. These Since Scala compiles to the JVM, SwiftVis2, like many other are very small sub-projects, but they enable users to avoid visualization libraries, is cross-platform, meaning that it including graphics elements that they might not have as part will function well regardless of the user’s operating system. of their local installation of the JVM. 978-1-7281-7624-6/20/$31.00 ©2020 IEEE 317 DOI 10.1109/CSCI51800.2020.00061 1.2 Scala.js run the JVM, Scala Native applications can start running far more quickly, which may be a more noticeable factor than Scala.js is an open source Scala to JavaScript compiler overall performance in many use cases. They also use far with optimization, allowing developers to write Scala code less memory in many situations than what the JVM must for web applications. This project is fairly mature, as it allocate on startup. has existed for several years and is used in a number of For our purposes, the most challenging aspect of working professional environments. In February of 2020, the Scala.js with Scala Native has been finding a good rendering solu- project officially came out with version 1.0 [8]. Scala.js is tion. The graphics libraries we have employed are low-level, highly interoperable, allowing the programmer to use any and have made some aspects of plotting more difficult than JavaScript library with their Scala code. It supports both they would be with the JVM or with Scala.js. strong and dynamic typing, with a large standard library and support for IDEs. The JavaScript code produced by Scala.js’ full optimization mode is comparable in performance, and 1.4 Existing Solutions often faster, than handwritten JavaScript code, though it is Though there are several other options for plotting in predictably illegible. It can, however, run up to three times Scala, to our knowledge, there is no other visualization slower than the JVM, and compilation itself can be lengthy. library compiling to the full range of targets now supported Scala.js is expedient for our purposes because it allows by SwiftVis2. Of the noteworthy alternatives, EvilPlot [9] easy use of the HTML5 canvas within Scala code, providing provides support for Scala.js and the JVM, but not for Scala a well-documented, established, and easy to use method Native; Vegas [10] supports neither Native nor Scala.js. The of rendering the plots produced by SwiftVis2’s platform New Scala Plotting Library (NSPL) [11] provides support for agnostic backend using JavaScript. We believe that support all three platforms, but unfortunately lacks any documen- for Scala.js significantly expands the use cases of our library; tation beyond examples. Indeed, a common theme among SwiftVis2 plots could now be used for visualization within a many Scala plotting libraries is a lack of comprehensive web application, or embedded for use with a plot generator documentation: Vegas and the NSPL both lack an API or from user defined collections of data. Scala.js also includes function reference of any kind. directives for outputting code that can be called directly from JavaScript. We have just begun implementing this function- 2. Methods ality. Once in place, users could include the complied “.js” files on a website, and easily add plots with calls to plain 2.1 Achieving Cross-compilation JavaScript. SwiftVis2’s plots are represented as immutable Scala ob- 1.3 Scala Native jects defined by case classes. Each plot is able to render itself by calling methods on the Renderer interface. The core Scala Native provides “an optimizing ahead-of-time com- abstractions of SwiftVis2, and the rendering interface, do not piler and lightweight managed runtime designed specifically rely on external libraries. As a result, we were able to adapt for Scala.” Its first release, version 0.1, was made public them to be platform agnostic with only minimal changes in 2017, and it is currently in version 0.3.9. Like Scala.js, to make SwiftVis2 compatible with the older versions of Scala Native is open source and highly active. The main Scala supported by Scala Native. None of these changes advantages provided by Scala Native are its low-level func- affect performance. After the core of SwiftVis2 had been tionality: full support for pointers and dynamic memory made platform agnostic, we separated SwiftVis2’s various management are present in Scala Native. Much like Scala.js, Renderers into nested projects within SwiftVis2, so that Scala Native also offers a high level of interoperability, users could choose to compile SwiftVis2 with whichever allowing the programmer to call C code within their Scala Renderer they wished to use and ignore the requirements code. This has the advantage of allowing programmers ac- of working with any of the other Renderers.