Re: [Development] Qt for NaCl port

2014-06-16 Thread Sorvig Morten

On 11 Jun 2014, at 14:53, Thiago Macieira thiago.macie...@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







___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt for NaCl port

2014-06-13 Thread Thiago Macieira
Em qui 12 jun 2014, às 19:08:58, Daiwei Li escreveu:
  It doesn't matter.
  If you're volunteering to support it, it will be supported. If you're not
  volunteering to support and no one else volunteers, it won't be.
  Are you volunteering?
 
 Potentially, but I would require help, at least for getting continuous
 integration running unit/integration
 tests on Native Client and preventing future changes from breaking the port.

The Qt Project needs to decide whether it wants that platform as part of the 
CI. Then Digia needs to chime in if they have the ability to do it, since 
they're running the Qt Project CI.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt for NaCl port

2014-06-12 Thread Thiago Macieira
Em qui 12 jun 2014, às 18:25:20, Daiwei Li escreveu:
  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.
 
 I see. What about maintenance? This may not be the right place to ask this,
 but is
 Native Client a platform that Digia would want to support officially
 eventually?

It doesn't matter.

If you're volunteering to support it, it will be supported. If you're not 
volunteering to support and no one else volunteers, it won't be.

Are you volunteering?

 You probably will find problems in the QtNetwork library and, thus, Qt
 
  Quick's
  remote file and XML HTTP  Requests support.
 
 Ok, I'll be on the lookout for problems there.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt for NaCl port

2014-06-12 Thread Daiwei Li

 It doesn't matter.
 If you're volunteering to support it, it will be supported. If you're not
 volunteering to support and no one else volunteers, it won't be.
 Are you volunteering?


Potentially, but I would require help, at least for getting continuous
integration running unit/integration
tests on Native Client and preventing future changes from breaking the port.


On Thu, Jun 12, 2014 at 6:32 PM, Thiago Macieira thiago.macie...@intel.com
wrote:

 Em qui 12 jun 2014, às 18:25:20, Daiwei Li escreveu:
   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.
 
  I see. What about maintenance? This may not be the right place to ask
 this,
  but is
  Native Client a platform that Digia would want to support officially
  eventually?

 It doesn't matter.

 If you're volunteering to support it, it will be supported. If you're not
 volunteering to support and no one else volunteers, it won't be.

 Are you volunteering?

  You probably will find problems in the QtNetwork library and, thus, Qt
 
   Quick's
   remote file and XML HTTP  Requests support.
 
  Ok, I'll be on the lookout for problems there.

 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Qt for NaCl port

2014-06-11 Thread Thiago Macieira
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.

 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.

 Does anyone have experience with the Qt for NaCl project? Any
 tips/advice/considerations on attempting such a port?
 
 I sent a similar e-mail to interest a while ago and got a response
 about QmlWeb. While it looks interesting, it unfortunately won't work
 with C++ QObjects.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development