A few weeks ago, Paul blogged about the Lighthouse project. The unofficial goal of that project is to allow every Qt developer to port Qt to their favorite platform. Of course we like it when new platforms come along so we can put Lighthouse through its paces and share their experience. Google’s open source Native Client project seemed like a perfect opportunity. I’ve been playing with it on my creative fridays, and here’s what I’ve got so far:
The security part of NaCl is implemented as a code scanner/verifier, which runs when a program is loaded into NaCl, and makes sure the code being loaded does not contain any unsafe instruction sequences, eg jumps to arbitrary memory locations or self-modifying code. The compiler itself is not a part of the security system, it’s merely a help to produce a valid instruction stream that won’t be rejected by the scanner. This NaCl research paper has all the details.
So how did it go with Lighthouse? Pretty good! We’re not finished yet, but we got some real chemistry 🙂 with NaCl , really quickly. I especially enjoyed working with the new QWindowSurface and QGraphicsSystem classes, which allowed me to fill in the blanks with Native Client API calls and get results on screen right away.
The elastic nodes example running in Firefox
At this point, Qt for NaCl is at the level that QtCore and QtGui compiles with a minimum system-dependencies configuration. The event loop is up and running, with timers, mouse and half-way working keyboard input support. There is one font available (Native Client does not seem to have a font API yet, so each application has to bring their own fonts.) Several widgets work, as well as QGraphicsView (there seems to be an issue with pixmaps not showing up though). The QPainter rasterizer triggers an optimizer bug in the NaCl compiler, so I’ve left optimizations disabled for now. QThread should work, although we are still using the generic mutex-based QAtomic fallback, so multi-threaded performance might not be that great. Finally, NaCl event handling seems to be polling-based only, which means that all applications spin at 100% CPU usage – not quite our preferred style.
So, nice results for Lighthouse, but still work to do.