Sunday, December 28, 2008
The bad news: I found new bugs in the playback module! :D
When the AVController is paused, I haven't yet implemented a way to signal the main thread that it's paused. See, we have to check not one thread, but four. So that means we can't use a single flag, but four.
The problem is, we need to detect different conditions:
If the thread is invalid,
if the thread is valid but paused,
if the thread is running,
if the thread has stopped.
And this for each thread. But we need to check if the threads haven't aborted abruptly.
At least we're closer to getting this to work.
Update (28/Dec/2008, 11:41PM):
The play/pause bug has been fixed now :). No more deadlocks! Now we're going to test the Demo (the blue colored figurines in the screenshots) using AVController. But that'll be for another day, I need to go to sleep, it's very late already.
Saturday, December 27, 2008
Whenever I press "play/stop", the AVPlayer instance receives a play or a stop event (a Saya event, not a wxWidgets event - this is what makes it important, because it makes our core classes still toolkit independent). Same goes when I press "fast forward", "fast rewind" buttons, etc.
I'd post a screenshot, but a screenshot of a messagebox is pretty boring.
In any case, now I have the tools to start testing the playback framework I've been working so hard during these 4 months.
I'm so excited! I feel just like Dr. Frankenstein waiting for the thunder to bring my creature to life, mwahahahahah!
Friday, December 26, 2008
I also read two very interesting articles:
Top C++ Aha! moments"
Top C++ non-book publications
Thursday, December 25, 2008
That said, I'd like to complain about wxSlider. The wxWidgets code for the slider widget has this annoying behavior: If you click on anywhere in the slider, the slider reacts as if a pageup/pagedown had been pressed. I absolutely hate that. Sometimes I want to repeat or advance a DVD scene in VLC player, to have the player skip around 20 minutes or so because I didn't grab the slider control correctly. ARGH!
This can be solved by making the page size to 1/50 of the total slider length. It's still not perfect, but that's the only workaround. But I'm definitely considering writing my own slider control. Now, where was that native widgets implementation I saw the other day on the web?
Tuesday, December 23, 2008
The good news is that a lot of work has been done on Saya. Especially the last 2 days, because I got sick and had to stay at home, so that gave me a lot of free time :P
Here are some advancements that have been made:
- Since I was asked to code Saya in QT4 (as opposed to wxWidgets), I've been working really hard on getting rid of wxWidgets dependencies. So that means I had to make a lot of wrappers, substitute classes, etc. These include but are not limited to:
- A completely new, template-based, event handling system. Saya classes can now emit and receive their own events! Unfortunately there was no way to get around glib's (gtk) main_loop - but since even Qt made a wrapper around it, it's better to use what works. So I had to make a new wxWidgets event type to signal wxWidgets that a new Saya event has been queued. So far the only time I use an event is to signal the Main Frame that the currently-active project has changed.
- A completely new syApp class: Saya is becoming more like a cross-platform toolkit (with more and more files in the core/ path) and less like an application, but that doesn't worry me. The point is that I managed to invoke the wxWidgets UI with a function from the plain old main() function. This also means that we could turn Saya into a non-graphical tool.
- With the new syApp class (and its subclass wxSayaApp using wxWidgets), I no longer need the sayaEventHandler class, and I no longer need the main window to have its own functions for opening dialog boxes. All dialogs from now on are invoked by syApp. I even added a syFileSelector function. This also helped me remove some wxWidgets-specific includes.
- The new syString class (a class encapsulating a const char*) does everything we need from wxString, including efficient concatenation, conversion from various numeric types, printf-like formatting, etc. And because I added some conditional includes, you can convert from/to wxString without having to call a function (the only exception is when a wxWidgets function needs a const wxChar*, you need to do the casting specifically: wxString(mystring).
- Along with the new syString class, serialization and de-serialization will become piece of cake when I get to implement it.
The source code tree has been reorganized. Now we have the following directories:
ui/ (all the code using wxWidgets, and our main application)
saya/ (The directory for our video editing framework)
saya/core (The directory for our generic cross-platform application framework)
saya/timeline (The directory for our timeline-specific classes).
- Some bugs in the ioCommon namespace (I really have to put my namespaces in order) have been fixed, like renaming / deleting a file.
- Most classes have been moved to the private implementation parts, and this has helped me get rid of TONS of unnecessary includes. With these changes, we can recompile Saya (without -O2) from scratch in only 22 seconds.
- Memory handling has been given special care: For temporary objects, now we use std::auto_ptr whenever possible.
- I've created the following classes: AVPlayer, InputMonitor, PreviewMonitor (well it's now coded yet, but it'll be a minor adaptation of InputMonitor). AVPlayer also inherits syEvtHandler, meaning it can catch events you send. I'm *very* close to actually being able to reproduce video thanks to this.
So that's the good news. The not-so-good news is that I haven't been able to get video playback to actually work... yet. It's a very steep curve, but I'm sure all my work hasn't been in vain. I promise that next year I'll actually have a workable media player for Saya.
Merry Christmas, and happy new year!
Friday, December 19, 2008
Here's the forum post which made me consider everything:
After giving a glimpse over various automation tools, two tools called my attention: SCons, and CMake.
SCons is a tool supposedly cross-platform tool which I need to use at work. It uses python scripts. UGH, python! So, why did it call my attention? Because of its complexity and python requirements. In other words, it's a tool I would NOT like to use :)
The alternative was CMake. We know CMake has support for Code::Blocks projects and workspaces (that's a plus!). But I was delighted when I realized that CMake is the tool used to build KDE 4.
The best part of using CMake is that the only thing you need is:
a) Your compiler
Autotools and SCons, on the other hand, require you to install more scripting languages (i.e. perl, python) to make your file. This is REALLY what I like about CMake. It's lean.
Next year I'll start to work on being able to compile Saya with CMake.
Monday, December 8, 2008
Oh, just for your amusement, here's a copy of the e-mail I got from blogger:
淑丽 has left a new comment on your post "Saya developers meeting #3 (2008-11-28): Summary o...":
(VideoEditorSoft dot com - link de-httpified to prevent more spamming) provides free easy and popular Video Editor,
DVD Video Editor,
DVD Video Author.
If you are looking for video Editor for Apple Mac OS X program, please refer to Mac Video Editor,
Mac DVD Video Editor.
Posted by 淑丽 to Saya Video Editor official Blog at December 7, 2008 9:49 PM
Just so you know, his profile id is available at http://www.blogger.com/profile/12311597430950642116 If he tries to post again, I'll notify blogger so they can kick him out. :)
By the way, I really *DON'T* recommend downloading from his site, who knows if that thing's got a virus or something.
Sunday, December 7, 2008
So I began to replace the references to std::string in the timeline classes, and designed a new form to serialize them.
I made a C++ wrapper for ostringstream so that I could later switch classes in case I needed to. Guess what, I did switch later. Because I also needed to design a std::string lightweight replacement (I've called it syString), I ended up adding methods to concatenate strings in an efficient way. I use the "size doubling" technique, up to a certain point, then the string only increases by amounts of 64K. I haven't tested this strategy well, but I may change the strategy in the future by adding a static parameter.
I also reorganized the header files and cleaned up a lot of bloat. Some classes included the STL (I still need std::map and std::vector) for fixed types, so I moved the std inclusion to the CPP.
I also fixed the precompiled headers inclusion, and removed a lot of unneeded wxWidgets includes from the GUI files.
As a result of this optimization, I've cut compilation time by 33%, yay! :)
Unfortunately, I stopped working on the playback engine, but I'll start. Playback functionality needs to be finished and tested ASAP.