27
Jul
June / July Development Update (Part 2 of 3)
Written by on .
Welcome to Part 2 of my update, where I will dive much deeper into the technical accomplishments of the past 2 months. I also have some screenshots to share, as well as a new video to demonstrate the current state of the project. So, here we go!
Timeline Improvements
As you can see from the screenshot, I've made many improvements to the timeline look & feel. I have also done more work in the "theme-ability" of the timeline, and it is now very easy to give the entire timeline a different look using CSS. I am very excited to see what themes the community will create once everything is released. Conceivably, the timeline could be themed to look and behave like any video editing application out there.
The JavaScript that powers the timeline has also been through a major refactor, and is very well organized now. Each primary element (i.e. clip, track, timeline, playhead, etc...) has it's own JS file, and is very easy to debug. I have also added in a debug panel, for when working on the timeline source code in Google Chrome.
 |
| Debugging Timeline in Google Chrome |
Snapping Improvements
 |
| New Snapping Feature (i.e. blue line) |
One of the coolest features I've completed over the past many weeks is a brand new snapping engine for the timeline. Basically, every element on the timeline (including the playhead) can be snapped/aligned in real-time, as you drag a clip or transition around. As the clip approaches a "snapping coordinate", a line fades in as a visual cue, and fades out after you drop it or move past it. It certainly makes the timeline easier to use, as aligning clips, transitions, and audio is a very critical part of the average video editing work flow.
Memory Leaks & Bug Fixes
As everything becomes more functional, some things are much easier to trigger, such as memory leaks. And one fun anecdote about a video editing application, they use a ton of memory on the heap, and memory leaks can sky rocket to all your remaining memory in about 5 seconds. In other words, these types of memory leaks are fairly easy to spot. And thus, all of the memory leaks that have been found so far are now fixed. And many of my tests include code that runs for long periods of time, and that has given me a lot of confidence in the underlying library (i.e. libopenshot), and the general stability of the platform.