It pours.
Hey yall, if it seems like I’ve been a little disconnected the past few days it’s because I’m in the middle of mid-terms! I’ll be back to my normal capacity probably by next week.
P.S., Happy Early Halloween! Guess who’s going to go trick-or-treating. 
After much deliberation, hair-pulling, and running around my wee little room screaming at the debugger, I’ve managed to put together a decently stable (as in, it now crashes less often that it used to) build that supports Flash plugins– you can check it out of the SVN now as revision six.
I also spent a bit of time on optimization to take more advantage of multi-core processors. Previously, WebView::isDirty did a synchronous query of the internal WebViewProxy object on the core thread to test for dirtiness– I realized a better way to implement this was for the internal WebViewProxy object to directly update a local member of the WebView object on the main thread via a mutex so that calling the function doesn’t cause any blocking. Also, since the mutex would only be locked if the dirtiness state was being set to true (it’s only set to false during the synchronous WebView::render), if the mutex failed to be acquired instantly, WebView::isDirty immediately returns true.
Furthermore, I implemented a compromise to issue 3 and that is that WebView::isDirty now asynchronously flags the associated WebViewProxy on the core thread to begin layout/painting of the frame if it is dirty. This allows at least part of the rendering to take place on another thread concurrently with any blitting preparations that may take place on the main thread (such as the locking of a HardwarePixelBuffer in Ogre3D).
Testing shows that these additions have significantly improved the performance of several operations (such as scrolling, javascript/canvas animation, etc.)– I was seeing about a 20% improvement in the rendering speed of Google Maps.
Success!
Turns out my guess about what why the Flash plugins weren’t continuously rendering was right– I set up a repeating timer to intermittently do a Peek/Translate/Dispatch on the internal thread and suddenly everything was animating.
Mouse/keyboard input still was having issues and so I tried a lot of elaborate solutions to try and solve it– creating off-screen dummy windows, manually injecting window messages, etcetera. I eventually emulated Chrome’s existing input-handling routines for windowless plugins and got it working.
Windowed plugins still proved to be a major problem and I wrestled a lot with it over the period of a few days. It’s embarassing to admit that the final solution was really quite simple: when loading a plugin, I override the wmode parameter to force all Flash plugins to be loaded as windowless.
There were several other complex issues I had to contend with as well such as the throttling of certain messages, the timing of the peek/translate/dispatch cycle, and destruction order but I think the majority of the implementation is there. It’s still not entirely stable yet and so I’m not going to commit the new changes to the SVN just yet.
If you’re feeling curious, you can download a demo to test out the early Flash support. A few notes:
- Try to run it in windowed mode, you may need to close manually if Esc fails to work.
- F1: Print FPS to console
- F2: Navigate to Google
- F3: Toggle between forced-rendering and normal-rendering.
- Forced-rendering is useful for when the rendering freezes (it’s one of the bugs I’m working on)
I spent a bit more time working on Flash support– after fiddling around, I realized I could hook in a ‘WebPluginDelegate’ to handle the load of a plugin and duly wrap it however I want (foregoing any muckery with the NPAPI). After a few hours, I had Flash (almost) rendering! Er, well, only the first frame of any windowless (wmode=transparent) Flash movie:
As for why it stops at the first frame, it seems almost as if the plugin’s internal message loop isn’t being processed– I think it’s trying to post messages via the WinAPI but is being negated by the fact that I’m running it all in a seperate thread from the UI and am not passing any sort of HWND to the plugin. Oh well, it’s gonna take a bit more hacking to get this implemented. 
In an attempt to better organize discussion of Awesomium (replying to comments just isn’t cutting it), I’ve started a discussion group over at Google Groups. I normally would set up a big forum and wiki on my own webspace but users have been having trouble with e-mail confirmations (apparently my server resides in a blacklisted IP block).
Also, I’ve started using the issue tracker on the Google Code project page to coordinate and record issues/bugs/enhancements. If you spot a bug or simply want to make a suggestion about Awesomium, please feel free to add it to the issue tracker if it doesn’t already exist.
As for the future of Awesomium, there are several things I’m currently working on and hoping to get implemented. Support for true transparent backgrounds is one that tops my list as there is significant demand for such a feature. I haven’t had much luck getting this implemented natively and so I may end up altering the Chromium source– we’ll see how my hacking attempts go.
Another big thing I’ve been hearing requests for lately is support for Flash and other plugins. There’s several problems right now getting the Flash plugin to work: it requires a window handle (we have none), it renders directly to the window, and it isn’t painted with the WebView when invoking an offscreen paint. Nevertheless, I’ve got an idea: attempt to force the Flash plugin to always initialize in windowless mode (thereby it doesn’t require a window handle) and then intercept whenever it paints offscreen to its HDC (requires modification to Chromium). I’m still a noob at the NPAPI however and so to hone my skills, I’m currently working on creating a standalone plugin execution sandbox (so I can embed plugins like Flash without a browser).
