Making ABeamer smaller

The previous version, already reduced the final client library size, by joining all typescript source code, remove the inner namespaces and eliminating all the exports of all source functions that start with underscore, allowing to compact more the code, and then compiling all the code again. In this version, I take one step further by creating two version:

  • abeamer-debug.min.js - It contains the code of just like it was generated in the version 1.3.
  • abeamer.min.js - It removes all the debug code used to log the execution.

The new abeamer.min.js is smaller and faster, at the cost of loosing its internal logging capabilities.
If you need to log, to understand what is happening behind scenes, just replace it with the abeamer-debug.min.js.
In the future more versions will be created to make ABeamer lighter by disabling certain features.
The version 2.x, will be smaller since parts of the code will be passed into the plugins. I’m delaying for now this decision to make sure that all the breaking changes are done at once, avoiding many bumps on the major version number.

Internet presence

Most of the recent work as been done on the internet presence, as described in my previous post, and that work continued in this version, by changing the build processes and by removing unnecessary code regarding the github repos to make easier for me to test offline the blog, gallery and documentation.
Very soon, the blog will also support comments.

Delaying the start of teleportation

The brand new feature of this version is the delay of the start of teleportation, but since it’s a more complex issue, I decided to create a separate post that you can read here.

What is next?

While working for now most in the internet presence, I have working to crush down many of items described in the roadmap and Roadmap updates.
But still maintaining in the back of my mind some critical aspects such as the video-sync task which will require a lot of research due to chrome auto-play policy, and the port of the core parts of the code to the plugins, in both cases will require breaking changes.
But one field I’m also doing research if how to improve the capabilities of the cloud render server, which is after all one the major key features.
The features that I expect to implement in future versions are:

  • Distributed server render. When a story requires heavy computational renders, a cloud server could distribute the render load by rendering a segment, usually a scene, in one server and other segment in another server, and then join the result.
  • Render multiple stories without shuting down the server. I don’t have a name for this feature yet, but in essence right now the server render agent for each story it has to do the following tasks:
    • Load the teleported story.
    • Inject the authorized plugins into the story.
    • Launch a chrome instance.
    • Open the page.
    • Loop each frame.
    • Shutdown chrome.
    • Exit.

This process is time consuming and it requires a chrome instance to be launched for each story, along with the render server agent. If a cloud render server needs to render a queue of stories, and if the render server agent was capable of receiving a story queue instead of one story only, it could reduce the total execution time with the following workflow:

  1. Launch a chrome instance.
  2. Load the first teleported story.
  3. Inject the authorized plugins into the story.
  4. Open the page.
  5. Loop each frame.
  6. If there are more stories in the queue move to the next story and goto to step 2.
  7. Shutdown chrome.
  8. Exit.

These 2 features are still in the research phase, and as soon as the internet presence is completed, the work on the ABeamer code will return at full steam.