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

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.

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

Project meeting @19/Dec/2016 cancelled due to no significant discoveries.

Fixed Visual Studio compilation CodePage problem.

Basic understanding of VixenLights program structure and pipeline.

Performance measuring?

Ref: VixenLights Ref: C# project locale Ref: 57531dd365fb88f9126ca9e7d05b11424460fada

If the system locale was set to something different than English, special characters in some source files may cause strange compilation failures.

Explicit CodePage settings need to be applied to some projects.

Add

28591

to default PropertyGroup in *.csproj files.

Ref: https://github.com/sall/vixen/pull/173

This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Read More