Lightworks for Linux is approaching its public testing phase. Lead Developer Rob Fearnside answers our questions about how it got to this stage
The Lightworks codebase is quite large - close to a million lines of code altogether - and some of it has been in existence for nearly twenty years. When we started the move to make it cross-platform eighteen months ago, we were faced with a number of challenges : How do you rewrite that much code in a sensible timeframe? How do you keep shipping Windows builds whilst the work is underway? Our solution was to avoid rewriting the Windows-specific code at all (it was, after all, tried, tested and optimized). Instead, we decided to move it to a new operating-system dependent layer which we engineered to have an OS independent interface. Once this was complete, we were then able to begin work on a Linux implementation of that same layer. In essence, the Lightworks code is now split in two - the OS-independent code (eg. editing, play-engine, etc) which uses the OS-dependent code (eg. file access, threading, etc).
The OS independent code accounts for about 97% of the total codebase. The bulk of the work in porting to Linux was actually in re-engineering the existing code, not in writing the Linux-specific layer.
In order to get the very best performance, Lightworks' Windows layer uses Direct3D for all the video scaling, effects and colour-space conversion. Linux of course doesn't have Direct3D, so we had to reimplement all the Linux GPU specific code using OpenGL. The multi-threaded nature of the Lightworks software made some of the OpenGL support difficult to write. In particular, updating video/playback images from a non-ui thread was a real challenge, and for a while I wasn't sure it was even possible, but after much head scratching, we found a solution that worked.
The initial goal with the Linux version was to try to make it as similar to the Windows version as possible. Now, if you run the two versions side by side, it's extremely difficult to tell them apart, so in that sense, I'm very pleased with the results. Additionally, because we went through the process of splitting the code into OS dependent and independent pieces, we've ended up with a cleaner, more maintainable codebase which will benefit all of our future development across all platforms
.