Daily Update 20

I haven't coded any big features in the last few days, mostly done small edits in the code preparing for the final submission and a couple of bug-fixes relating to the GUI. With the graphical user interface complete, I think pretty much all features I proposed in the original plan are completed. Of course, there are a lot of things that could be further developed and ideas that could be implemented in the future, but I don't want to implement anything too new in the last week of GSoC.

Since there aren't any serious programming tasks left, I'll spend the last week editing my code and also writing about GIFScript. Maybe I'll post some more examples and also some excerpts from the tool's features to demonstrate its capabilities. I'll also communicate with my mentor to make sure everything's alright with the submission.

Daily Update 19

Today I made some tweaks on the GUI, relating to error reporting and some convenience features, like line numbering. Syntax highlighting is now performed asynchronously, presumably making the interface more responsive, though GIFScript files are usually short. I started working on parenthesis matching, which might be a useful addition. Also made some minor tweaks related to the module loader. I'm happy with the basic editor, and the overall project seems to be slowly wrapping up.

I tried to push my recent code to GitHub towards the end of the day, but unfortunately Eclipse refused to submit. I'll check on the fix later, I think it might be related to a recent OS upgrade.

Daily Update 18

I haven't posted any updates lately, but I kept working on the GUI implementation as planned. The interface is quite straightforward, but a few unique features exist to help describing GIFs. One point I spent time on was creating a syntax-highlighted editor, which I used RichTextFX, a JavaFX based implementation of a flexible styled editor. Following the documentation and examples, it was easy to get decent results for JavaScript, but I might spend more time for code constructs specific to GIFScript.

Another problematic point was providing quick previews of the GIFs generated from the scripts. The current command line tool only reports the product once the whole frame rendering and compression steps are complete, a lengthy process as I mentioned earlier. I came up with a possible solution using Java runtime class loaders from my earlier work, but I'll have to work on it this week to actually get it working with multithreading.

I also worked a bit on some security features, to forbid any script run by the program from writing to files, since a normal script should only need read permissions.

I'm slightly behind my schedule since I was supposed to complete the GUI last week. But I don't think it will be problematic since the workload of the last weeks is much less.

Daily Update 17

Today I went through some JavaFX resources to refamiliarize myself with it. I'll be working on creating the interface for easing the scripting process this week, so I also did some planning on which features to implement. I didn't code any GUI today, I have things to complete left from last week. I worked on the GIF "streaming" feature I mentioned last time. I also made some small changes to the command line tool to make its usage more standard.

Daily Update 16

Lately, I've been compiling a few modules of my own for producing more complex GIFs. I have my modules for animating 2D plane geometry and chess moves more or less complete. I'm also working on a way to preview animations without spending time on encoding.

Next week, I'll be working on a basic IDE-style GUI for GIFScript, with editing and preview support. In preparation for that, I'm working on a detail I couldn't anticipate while I was writing my proposal. The problem is that it still takes time to fully encode a GIF, long enough to make it cumbersome to "re-run" a script each time the user wants to test a small visual change. To solve this issue, I've decided to implement a preview mode in the core tool, which only produces frames in sequence without encoding them into compressed GIFs, which would allow fast previewing from the GUI.

Daily Update 15

The last few days being "bayram" in my country, I missed blogging.

I worked on minor improvements and bug fixes this week. Implemented a lot of small details which should make GIFScript more self-consistent and easier to learn. Lately I've discovered that continuously transforming a subtracted area resulted in ugly looking glitches, possibly due to floating point errors combined with low resolution rasterization. I haven't come up with a perfect solution yet, but some small changes improved the glitchy behaviour.

Since I don't have much programming load this week, I'm also spending time on the to-be-published documentation. The guide isn't ready as many things can change, but just trying to write down the details inspired a lot of improvements in GIFScript to smoothen its usage.

Daily Update 14

This week is allocated for refactoring and bug fixes, so I won't be working on any new features in particular. Today I spent time on some parts of the code which seemed unnecessarily complicated and did some refactoring. I decided to divide some of my larger classes into more meaningful subunits. As always, I also did some testing. In particular, I attempted to make a module out of a opensource DSP library I found online, which could produce nice animations in the context of DSP.

Daily Update 13

Since the functionality scheduled for this week is already complete, I took the time today to test my progress and make a few additions to the interpreter. I added some convenience methods to the GIFScript library, like more concise ways to initialize and apply simple point-to-point tweens.

Finally, worked on a sketch for the documentation/guide for GIFScript, decided how it could look like. If I can, I'd like to publish at least some kind of tutorial earlier than I planned, giving me more time before the program ends to alter things depending on the feedback I  receive.

Daily Update 12

Today I completed the module functionality, both for loading libraries into the environment and exporting existing code as a GIFScript module. I tested my code for a few examples, which went well on both sides. As I mentioned earlier, modules are implemented as ZIP archives containing code and resources. The code contents get interpreted by Nashorn in order specified by a initialisation file when a module is loaded.

Tomorrow I plan to start working on more complex modules to further test the implementation.

Daily Update 11

Today, I started working on modules. I decided to implement modules simply as ZIP archives containing both code and resource files along with a descriptor file showing how GIFScript should handle each. Once a module is created, users will be able to dynamically load these packages in their animation scripts, enabling their functions. A packager tool available through the command line will be used to bundle JavaScript code and possibly images into module files for reuse.

I implemented the basics of the "packager", reading through the documentation for Java's ZIP utilities. Java's interface for compressing and decompressing ZIPs is pretty straightforward, but the code for loading these to the environment is not done yet, so I couldn't actually test the concept yet.

Daily Update 10

I couldn't work much on GIFScript the last few days, I had an exam that I had to study for. But now that it is over, I can once again focus on my programming tasks.

This week I'm supposed to implement "modules", or packed animation libraries that provide access to reused functionality. These could both involve JavaScript code and also resources like images, icons or fonts. Some example modules I thought of earlier are a 2D plotting library, a library for drawing probability distributions and one just animating chess moves. Thinking it will be useful, I spent some time today on a GIF demonstrating a genetic TSP algorithm work on the problem of travelling around Turkey.

Of course, the JS code is pretty lengthy, about 400 lines, due to the genetic algorithm. Completing this weeks work, I'll make it possible to separate the algorithm into a TSP solver module, leaving only 10-20 lines of GIF related code in the script as it should be. I think it'll be easy to implement modules with most of the scripting functions ready, I hope to finish early and focus on other details later in the week.

As a side note, GIFScript is now available under the MIT license, GitHub.

Daily Update 9

As I mentioned earlier, the past week went by mostly working on GIFScript's internals. I implemented some performance improvements, changed how tweens are stored and computed, and most importantly, I started working on my own GIF exporter. One thing I'm working on is a way to generate color tables before actually rasterizing a frame, which will save a lot of memory when generating large GIFs. The exporter is not done yet, but I'll probably make it usable by this week.

Thinking I've been working too much on the technical side lately, today I decided to make a detour and produce something more concrete. I parsed a long list of default color names for use in scripts. I implemented basic relative positioning on the scene, which I might develop even further later. Finally, I attempted to reproduce the quantum tunneling animation in GIFScript as an example by writing a more general numerical solver in Javascript, but it turned out to be more time-consuming than I anticipated, so I'll complete it later.

Daily Update 8

I spent the first day of the week with some modifications to the GIF writer, I completed some details left from last week. I rewrote parts of my text rendering code, fixing a few bugs relating to how Java graphics handle text. I started planning how I can replace Java's standard image exporter with my own code, to improve performance and GIF quality and for better integration. I laid the groundwork for the replacement, tested some prototype code. I'll probably spend this week with improvements.

Daily Update 7

The last two days were spent on animation functionality and general modifications to the code. I improved the tween engine, earlier the intermediate values of a property were precomputed and stored in a vector to be loaded as a frame passes. However, thinking that the cost of computing values is much lower than storing them in memory, I worked on a more flexible "pipelining" system.

I decided to start working on my list of to-dos which I accumulated in past weeks with details I didn't want to spend time on earlier. I cleared up nearly half of the tasks, with changes relating to functionality, better code quality and performance.

Daily Update 6

I haven't been blogging much the last few days, but I kept working on an animation system for the engine. I've been spending most of my time on a flexible tweening mechanism for scripting complex behaviour with minimal code. I exploited JavaScript's functional programming capabilities, and since Nashorn handles most of the interfacing, the implementation was pretty straightforward. However, I still need some time to make things feel more natural for the user.

This week and the next I'm supposed to develop the internal representation of animations in GIFScript, meaning I'll improve the translation process in the background. With this in mind, I set up cleaner error handling for scripts. I also worked on the rendering code, the previous naive implementation would occasionally fill up the Java heap space for GIFs with large dimensions and 500+ frames. Now using up all heap space is much more difficult, and probably a heap error won't be a problem for mainstream GIFs.

Finally, I did some profiling to help me decide where to head later. I'm actually happy with the performance, but as the frame count increases to more than 500, the run time can jump to a noticeable few seconds. It turns out that roughly 95% of the program time is spent on writing frames to a GIF file, the cost of interpretation is very small even with complex mathematics involved. While Nashorn is working pretty efficiently, Java's standard image exporting functionality seems to be slow. I'll optimize this later next week, for the time being I'll focus on more urgent tasks in my schedule.

Daily Update 5

As I mentioned earlier, I spent my time today on text rendering and importing image files. I built a small resource management system to make things easier when loading files from scripts. There are a few rough edges in the rendering, for instance, vectorized text does not interact with path operations I wrote for geometric shapes earlier. I'll fix these later to make the system more consistent.

Daily Update 4

I spent a lot of time today working on more higher level features for the renderer. I interfaced different types of parametrized compound curves. Implemented composed paths and some area combination functions typically found in vector graphics editors. I implemented nestable groups and geometric transformations for more complex operations. I did a lot of testing and fixed some hidden bugs mostly relating to the maths.

I again prepared a simple GIF demonstrating some features I spent the day on, showing how a relatively complicated 2D curve is parametrized by two sinusoidal components, visualized by the rotating circles. It shows how applying transformations to grouped objects can be helpful.

Parametrizing a curve.

I'll spend one or two more days on static drawing features, perhaps implement vectorized text and imported images. Then, hopefully, I'll complete this week by coding more dynamic components like parametrized motion tweens, keeping up with my schedule.

Daily Update 3

Today was a relatively slow day: I mostly worked on details in the background. I implemented primitive error reporting for scripts, to be improved in the future for a more user-friendly interface. Altered how transformations are applied, in preparation for composite/grouped objects. I also spent time on some convenience functions for utilizing primitives in scripts.

Going with my mentor's advice, I've decided to stay more focused and push the core functionality first. So I postponed secondary tasks like GIF compression and antialiasing until the fourth week, when I'll have mostly completed animation scripting features according to my GSoC proposal.

Daily Update 2

Today I continued implementing scripting functionality. Tidied up the code from yesterday a bit, made some alterations in the class hierarchy for renderable objects. Added some more geometric primitives (circles, polygons) and laid the groundwork for more control over strokes and fills of each shape. I also worked on geometric transformations, but these aren't reflected to the JavaScript side yet.

Daily Update 1

In the last few days I've worked on coding the skeleton of the program, and on how the JavaScript code is handled behind the scenes. I implemented line primitives, and other geometric shapes should be quite easy to add in the upcoming days. I also wrote a GIF encoder using Java's standard library, but there is still room for improvement, the GIFs produced aren't really optimized for size.

After coding the functionality, I wrote my first script, a spinning cube.

Spinning cube, generated with GIFScript [code]

Of course, the 3D math is dealt by the script itself as a demonstration, there is no built-in support for 3D at this time. But trying to code the cube, I realised that a higher level mathematics library would be very useful. I'll work on embedding a JavaScript math library (maybe math.js or "numbers") into the GIFScript environment. I also realised I'll have to add some anti-aliasing, primitive shapes tend to look ugly right now.

Current progress

As the coding period will start next week, I'm mostly going through documentation these days to familiarize myself with the libraries I will be using. My finals are just over, and I've spent most of my last days learning how to use Nashorn, coding small samples involving scripts along the way. I'm also reading through Java's image processing functionality.

In the upcoming days, I'm planning to start working on a prototype, to demonstrate the concept and also to discover the technical challenges involved in the project I might have missed. The goal is to complete a minimal version before this Friday, and hopefully display a few primitive GIFs myself. I imagine the project becoming more persuasive once I get some concrete product.

About GIFScript

This summer I'll be working on "GIFScript" for GSoC. GIFScript will be a tool for generating animated images from scripts, providing a way to create expressive animations by writing code, hopefully with minimal design loads. The users will use a flavoured version of JavaScript to enter the code, which will then be translated in the background into a GIF file.

The motivation behind GIFScript is that some animations are quite difficult to produce using traditional design tools with point-and-click interfaces, whereas they can be constructed relatively simply from their underlying mathematical ideas. On the other hand, these animations have unparalleled expressiveness in conveying abstract ideas, especially in more "mathematical" fields. GIFScript aims to provide technically oriented people who would need such GIFs greater expressive power, as it reduces the design process to writing code.

Demonstrating quicksort. [1]

Wikipedia, with an incredible library of fascinating technical animations was a source of inspiration for me, and I think there are quite a few worth sharing here, to prove the point.

Decomposing a function into its Fourier series. [2]

Mathematics and computer science aren't the only fields which could benefit from GIFScript. Any field of activity which can be visualized could go well with GIFScript. If designed well, GIFScript could be used to animate physical wavefunctions (which are quite interesting to watch actually), biological processes, chemical reactions or even more trivial things like animating the first few moves of a game of Go or chess.

Quantum tunneling, a particle interacts with a "wall". [3]

One planned feature I think will be useful in this aspect will be creating and sharing "modules", like libraries for GIFScript. User created modules will be packages containing visual assets (image files) and Javascript code, tailored for specific animation needs. For instance there could be a module for animating geometry on the 2D plane, one for chemical reactions and another just for scripting/animating sort algorithms.

Drawing a hypocycloid. [4]

So rapid production and practicality is key for GIFScript, all achieved while maintaining the flexibility and expressiveness required from visual designs.  Creating GIFs with the tool should be significantly easier than than they are with traditional tools to make using the tool meaningful. This part is quite challenging to get right, but I hope at the end the tool will achieve its goals with the help of the feedback I receive from potential users.

Sources:

[1] Wikipedia, en:User:RolandH, link

[2] Wikpedia, User:LucasVB, link

[3] Wikipedia, User:Yuvalr, link

[4] Sam Derbyshire at the English language Wikipedia