c►Vixen

Vixen project

Project meeting @20/Feb/2017 cancelled due to no significant discoveries. Supervisor was not in the college @27/Feb/2017.

I added a spearate playback path to Vixen, and successfully playback the exported sequence to the controllers. The application uses only ~6% CPU time with 50 FPS playback. All active controllers are running at their specified frame rates too.

Read More

c►Vixen

Vixen project

Using the export function from sequence editor, all output channels from all controllers can be exported with specific time interval.

The timebase used for exportation was a manual timebase, so the exported output interval is kept constant and unrelated to export time.

The export pipeline only supports 8-bit commands, might be a potential problem?

Another export format was implemented, to match the playback format used in TCPLinky controller. Ref: 830a17bb445aab1c98ddd44540cc77a0b701177b

The resolutionComboBox in the original application can only specify a time interval of 25, 50 or 100 ms. It was modified to allow custom values. Ref: e882fd9d429b9c00a0fd549e46805058c82849b2

c►Vixen

Vixen project

Implemented TCPLinky custom output controller module, based on BlinkyLinky. At least there is an actual controller that can be offloaded onto a different machine to simulate real world scenarios.

Display interface was implemented using Qt with OpenGL, very fast with low CPU usage (<2% @50fps). Controller communicates using a single TCP connection.

It can dump data from output channels to a file and directly playback from the dump later. Only minimal post processing involved in playback, so the rendering speed is very fast and possible on an embedded platform. (Pre-render the sequence from a high performance computer?)

The sequence can also be exported from the sequence editor.

Ref: 17fc24ce32e9d803016f7573b225710089a80041 Ref: c82e16d0acf51043ae33f8afea209061bb6042e6

c►Vixen

Vixen project

Using hot path analysis from Visual Studio performance profiler to analysis the most time consuming code segment.

Bad performance at the first 50 seconds is still unclear: Trying to catch up with the controller? Waiting for responses from unconnected controllers?

Most of CPU time wasted in output device command generation, specifically C# reflection calling the correct handler. Preview rendering also uses some resources, but not too critical.

c►Vixen

Vixen project

Performance profiling using Visual Studio performance sessions (sampling profiler). Instrumentation logging added to record performance data.

Using Makefile and varies Linux tools to convert performance texts to CSV tables. Import CSV into Excel, plotting line diagrams.

Full single core CPU usage (50% total) during first 50 seconds with low (5~10) fps preview & controller refresh rate. Afterwards, CPU usage varies (from 20% to 100% total), achieving target refresh rate (20 fps controllers, 20 fps preview), but frame rates are not stable.

Ref: Makefile Ref: 5002c640a54ab1b3fbc8736c125aba7a14b46d1a