[Development] Qt for NaCl port

[Sorvig Morten]

On 11 Jun 2014, at 14:53, Thiago Macieira <thiago.macieira at intel.com> wrote:

> Em ter 10 jun 2014, às 21:33:44, Daiwei Li escreveu:
>> Hello,
>> 
>> I'm investigating porting an existing C++/QML application to Google
>> NaCl, and I found that Qt had attempted a port a couple years ago:
>> http://qt-project.org/wiki/Qt_for_Google_Native_Client. From what I've
>> found online, it looks like it's unsupported and no longer works with
>> the latest Qt and NaCl toolchain. Does anyone know the history of this
>> project and why it was abandoned? If I can revive the port to work
>> with the latest NaCl toolchain, is that something that could be
>> considered for upstreaming?
> 
> Yes, it would be welcome in the Qt Project. The reason why it didn't go any 
> further is that people probably got busy and did not have the time to continue 
> supporting it.

In addition to lack of time:
- Native client was still a moving target. For example, the binaries I produced back then no longer work on the current Chrome.
- Qt moved in a “non-portable” direction with V8.

Now the outlook is better: We can run V4 in interpreted mode. The native client project is more stable. (There are still bugs: the most recent PNaCl toolchain miscompiles QtBase and produces a binary which won’t verify as safe.)

Further details from the previous porting effort (with a "from memory” disclaimer):
- There is a basic platform plugin with raster graphics and event handling support.
- QtWidgets and Graphics View worked.
- Qt Quick 1/raster/JavaScriptCore worked.
- Fonts are tricky: There’s a pepper API to enumerate system fonts, measure and render text but there’s no way to access the font files. As a workaround I bundled qtbase/lib/fonts/ .

> 
>> I'm currently only looking into porting what's necessary for getting
>> the QML engine/renderer running. Can anyone familiar with NaCl think
>> of any showstoppers for this subset of Qt functionality? It looks like
>> NaCl has an implementation of OpenGLES2, and worst case, if it doesn't
>> support JIT, V4 has an interpreter option.
> 
> You probably will find problems in the QtNetwork library and, thus, Qt Quick's 
> remote file and XML HTTP  Requests support.

- Networking: I implemented a QNetworkAccessManager backend which meant that Qt Quick apps could do requests back to the host (following the same-origin policy). This was sufficient for loading Qt Quick modules and resources, but not for our flickr example.

It was kind of interesting to find web apps _more_ restricted than native apps in this regard, when “openness” us normally one of the virtues associated with the web platform. These days there is CORS and JSONP so perhaps the situation is better.

- OpenGL: I ran into trouble resolving the OpenGL API functions. Unlike other platforms, NaCl’s gl2.h -provides the OpenGL API using macros:

  #define glActiveTexture GLES2_GET_FUN(ActiveTexture)

qopenglfunctions.h promptly undefines them:

  // Undefine any macros from GLEW, qopenglextensions_p.h, etc that
  // may interfere with the definition of QOpenGLFunctions.
  #undef glActiveTexture

- V4/JIT. NaCl has support for JIT, in the form of nacl_dyncode_create/modify/delete. I’m not sure how (if at all) this works with PNaCl. In any case we can start out with with interpreted V4.

Morten