Challenge Overview
For the Hercules client, we are going to be doing some work that involves a couple of their drawing technologies, name "pxCore" and "pxScene". The links below offer a lot more details on these particular technologies. pxCore is a C++ graphics library that is used on a wide variety of embedded devices that the client distributes. pxscene is a wrapper application around pxCore that exposes the drawing APIs to Javascript through Node and V8.
The client is concerned that Node and V8 are too "heavy" for their low-powered embedded devices. To this end, we have been working at integrating duktape (http://duktape.org/) into pxScene, replacing Node. This has gone well.Pxscene
Pxscene is a platform independent drawing platform / app that will be used on a wide variety of embedded devices for the Hercules client. You can find more information here, and you can download the app to be used for testing: http://www.pxscene.org/
The code for pxCore / pxscene is available in Github here:
Build instructions can be found here: https://github.com/pxscene/pxCore/blob/master/examples/pxScene2d/README.md
Step-by-step instructions to build the existing duktape integration on Ubuntu 16.04 can be found here:
https://github.com/topcoderinc/pxCore/blob/duktape_proof_of_concept/step-by-step-duktape-linux-build.md���
-DUSE_DUKTAPE is deprecated (not used).... Instead, we added two new cmake switches SUPPORT_NODE and SUPPORT_DUKTAPE. Both are enabled by default. The app now looks for a file called .sparkUseDuktape in the home directory to enable duktape.
You can validate the engine used through the "about.js" example (just type "about.js" in the address bar of pxScene). It will list the engine - either Node or duktape.
Requirements
The duktape integration is working well and is being tested by the client. One item that the client has mentioned they are slightly unsatisfied with is the memory used by pxScene when run with the duktape engine. The memory usage is less, but not as much less as they thought it would be, compared to node.
This challenge will provide two items:
* Memory profiling documentation when running the "fancy.js" example
* Updates to ensure that "fancy.js" runs inside 2MB or less of RAM (on Linux)
One note - any changes made to memory usage should be generic enough to save memory on most or all other examples. Don't just directly tweak specifically to the fancy.js example.
Documentation
For the profiling documentation, we want to run the fancy.js example and capture memory profile information. We want to know:
* How much memory is used by each part of the app
* If this memory usage changes while running, for example, is memory only used at boot up, or is a lot of memory used in one specific flow, like compiling / interpretting JS?
Updates
The goal for the client is to have the fancy.js example run in 2MB on Linux. This is a lofty goal, but we want to get as close to it as possilbe. Note that this would be with running pxscene against the fancy.js file like "./pxscene fancy.js", not loading the initial browser.js, which is the default.
Please provide a patch file against the commit hash f64a5b192e7bd5ebda2e7ac79fc84982b328b259 or later for this branch: https://github.com/pxscene/pxCore/tree/_duktape2
You must clearly document what is changed and why, either in clear in-line code documentation or in a separate document in your submission. We need to clearly communicate changes to the client, so your patch file and documentation must be very clear and thorough. Undocumented fixes won't be accepted - the more information we have on your submission, the better.
Deliverables
The patch file deliverable will be patch files against the "_duktape2" branch of this repo: https://github.com/pxscene/pxCore. You can find the branch here: https://github.com/pxscene/pxCore/tree/_duktape2
The profiling document should be a separate markdown file provided in your submission
You need to also make sure that any changes made in the patch file are clearly documented.
Documentation
In addition to your patch files, please include documentation on how to deploy the patch files and validate the changes.
Review Goals
For review, we want reviewers to explicitly check that the patch files are the bare minimum possible. This means that the patch files should be as lean as possible. We don't want changes for:
* Whitespace
* Brackets or tab alignment, or any other "structural" change
* Anything not related to the explicit requirements of a given patch
The client goes line-by-line to review each and every patch, so anything that's not quite right in a given patch raises all sorts of questions.
Video
No video is required for this challenge, but you must submit clear validation documentation