Re: [Development] New module QtCanvas3D now available
Hi Pasi, I'm super happy that we are finally getting support for WebGL in QML, so thanks for picking this up. I have some suggestions for further improvement though: We have a couple of items that implement QSGTextureProvider as an API. It would be really nice if we could use these directly as textures in WebGL. Image, ShaderEffectSource and any item that enables layer.enable: true. Because the Canvas3D runs on the GUI thread this is a bit problematic, of course, but lets talk more about that... I'd really like to see us move this to the proper render thread so we can avoid the context sharing and the FBO blitting. This would allow the to have a mode to run on beforeRendering or on afterRendering as well, and we could have the Canvas3D render directly into the base context of the window. That means we get multisampling even on embedded (which often doesn't have multisampled FBOs) and it saves us an extra blit AND it saves us the Graphics stack potentially stalling if the it is buffering up frames such that a display and a render FBO is not enough to let things run smoothly... This would be an awesome basis for Games with a HUD in QML on top. Running on the render thread also solves the problem of getting a hold of texture providers which would let you put parts of the UI into the scene and allow you to use WebGL to do transition effects.. And it is the only thing that will, in the end, guarantee performance. It does mean that we would have to queue up commands and then replay them on the render thread which creates a problem for glReadPixels, but we can solve that.. It isn't that common a function to call and it is expected to be slow, so we can take a hit on it. We can do something similar to QQuickWindow::grab() and stop the Gui/JS thread until the stuff is rendered, grab the results and then send it back. the QQuickWindow::scheduleRenderJob() API I added in 5.4 might be a good candidate to do something like that (though with a new schedule mode, something like ScheduleAndBlockWithAGLContext. Some smaller stuff: - The docs say it is an OpenGL-like implementation. Isn't it trying to be a WebGL implementation? It would be great if we could link to the official WebGL specification and outline in which areas we are different. - interaction example crashes on MacOS: backtrace http://hastebin.com/ufahatuqud.coffee - jsonmodels example uses Enterprise Controls. I don't think we should have dependencies on commercial only packages in the open source repos. If we do, at least put them somewhere out of sight, like into tests/manual/ or something. It gives a really bad impression. - You are connecting to QQuickWindow::sceneGraphInvalidated. In Qt 5.4, items which have contents have this signal as well, so you can connect to QQuickItem::sceneGraphInvalidated to avoid keeping track of when the QQuickWindow comes and goes (in case of reparenting and such.) - sceneGraphInvalidated signals should in almost all cases be handled synchronously. For Canvas3D shutdown, you connect Queued, which implies that once you get to shutdown, m_glContextQt will be a dangling pointer, which you continue to use. Only for logging, but still.. - Do not ever use QMetaMethod::invokeMethod in graphics code. It is slow... Post events or set up connections from signals you emit. - Can I suggest switching to categorized logging? - I'm really not happy about exposing devicePixelRatio in the public JS/QML API of Canvas3D... - In the QML files, you say called once on the Scene Graph Render thread and called to render on the render thread, but from what I can tell all WebGL rendering happens on the GUI thread. - Can we find some compatibly licensed demo and include that? For both the sake of verifying compatibility and for the sake of having a nice demo that is not a rotating cube? :) - The CanvasImageTexture class is doing some of what the QQuickPixmap classes are already doing. Don't know if we could share something there to simplify the effort a bit and to make background threaded loading and such possible. If we could get a hold of texture providers (like Image) these are available for free, of course. cheers, Gunnar On 20 Aug 2014, at 15:27, Keränen Pasi pasi.kera...@digia.com wrote: Hi, As part of Lars’s blog post some of you may have noticed that a new module called QtCanvas3D became available at https://qt.gitorious.org/qt/qtcanvas3d QtCanvas3D module is a lightweight implementation of a QML canvas component that allows you to get a 3D context object that you can then use to call WebGL like API from Qt QML JavaScript code. Included examples and documentation should help you get started, just be aware that prior knowledge of similar APIs e.g. OpenGL ES or WebGL is of great help in understanding how the API works. While the API implementation should be complete and should run on all desktop systems, the module is still of preview quality as it
Re: [Development] New module QtCanvas3D now available
On Wednesday 20 August 2014 13:27:54 Keränen Pasi wrote: Hi, As part of Lars’s blog post some of you may have noticed that a new module called QtCanvas3D became available at https://qt.gitorious.org/qt/qtcanvas3d Just for the sake of Qt Project procedures: This is my +1 vote as a Maintainer for the creation of the new module. From the descriptions given, this seems to complement Qt3D and Qt Quick 2 itself. it would have been preferable to add the new library and Qt Quick items to one of the two existing repositories, but given that new licensing options are being requested, I think it's best to keep them separate. -- 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] New module QtCanvas3D now available
Hi Gunnar, Thanks for the comments, quite a lot to go through, but let me answer the simplest and shortest ones first. The docs say it is an OpenGL-like implementation. True, should say WebGL like, I have a list of differences on API level that I¹ve maintained when implementing the context, but I think we want to fix the TypedArray implementations first and then see if that changes anything on the behaviour level. jsonmodels example uses Enterprise Controls. The example does have option to use the standard controls as well.. Just wanted to show integration with both (how it is the same basically). Do not ever use QMetaMethod::invokeMethod in graphics code. Good catch, it¹s a leftover from when the rendering was done on render thread, it was the only way to ensure the call really happened on that thread. Now it¹s redundant and switching to signal-slots should be done. I'm really not happy about exposing devicePixelRatio in the public JS/QML API of Canvas3DŠ I know, but it¹s the closest I could get to how HTML+WebGL does it and I really want to maintain the compatibility in this case. WebGL spec specifically states, no automatic DPI scaling must be applied, so the devicePixelRatio must be exposed to the JS code that then has to handle it. In the QML files, you say called once on the Scene Graph Render thread²Š Good catch, again leftovers from old implementation.. Can we find some compatibly licensed demo and include that? I¹ve ported the Three.js to this environment, you can find my branch of it at https://github.com/tronlec/three.js and I¹ve ported quite a bit of content on top of that (e.g. http://carvisualizer.plus360degrees.com/threejs/ ). It has been great to verify the functionality and to verify that the porting is as smooth as possible. Unfortunately most really nice content is copyrighted in incompatible way. Any suggestions for demo content with compatible license are most welcome! :) Regards, Pasi On 21/08/14 09:21, Gunnar Sletta gunnar.sle...@jolla.com wrote: Hi Pasi, I'm super happy that we are finally getting support for WebGL in QML, so thanks for picking this up. I have some suggestions for further improvement though: We have a couple of items that implement QSGTextureProvider as an API. It would be really nice if we could use these directly as textures in WebGL. Image, ShaderEffectSource and any item that enables layer.enable: true. Because the Canvas3D runs on the GUI thread this is a bit problematic, of course, but lets talk more about that... I'd really like to see us move this to the proper render thread so we can avoid the context sharing and the FBO blitting. This would allow the to have a mode to run on beforeRendering or on afterRendering as well, and we could have the Canvas3D render directly into the base context of the window. That means we get multisampling even on embedded (which often doesn't have multisampled FBOs) and it saves us an extra blit AND it saves us the Graphics stack potentially stalling if the it is buffering up frames such that a display and a render FBO is not enough to let things run smoothly... This would be an awesome basis for Games with a HUD in QML on top. Running on the render thread also solves the problem of getting a hold of texture providers which would let you put parts of the UI into the scene and allow you to use WebGL to do transition effects.. And it is the only thing that will, in the end, guarantee performance. It does mean that we would have to queue up commands and then replay them on the render thread which creates a problem for glReadPixels, but we can solve that.. It isn't that common a function to call and it is expected to be slow, so we can take a hit on it. We can do something similar to QQuickWindow::grab() and stop the Gui/JS thread until the stuff is rendered, grab the results and then send it back. the QQuickWindow::scheduleRenderJob() API I added in 5.4 might be a good candidate to do something like that (though with a new schedule mode, something like ScheduleAndBlockWithAGLContext. Some smaller stuff: - The docs say it is an OpenGL-like implementation. Isn't it trying to be a WebGL implementation? It would be great if we could link to the official WebGL specification and outline in which areas we are different. - interaction example crashes on MacOS: backtrace http://hastebin.com/ufahatuqud.coffee - jsonmodels example uses Enterprise Controls. I don't think we should have dependencies on commercial only packages in the open source repos. If we do, at least put them somewhere out of sight, like into tests/manual/ or something. It gives a really bad impression. - You are connecting to QQuickWindow::sceneGraphInvalidated. In Qt 5.4, items which have contents have this signal as well, so you can connect to QQuickItem::sceneGraphInvalidated to avoid keeping track of when the QQuickWindow comes and goes (in case of reparenting and such.) - sceneGraphInvalidated signals should in almost all cases be
Re: [Development] New module QtCanvas3D now available
Hi Thiego, Sorry didn¹t mean to jump the gun. Still a bit new to the Qt process. Just to clarify, the module is not yet part of ³Qt proper². I guess a more correct term for it would have been ³a playground type of preview of a potential new Qt module². Accepting it as new module in Qt proper should of course follow the process and yes, I do agree with your reasoning to keep this separate from Qt3D and Qt Quick 2 for now. Regards, Pasi On 21/08/14 09:45, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 20 August 2014 13:27:54 Keränen Pasi wrote: Hi, As part of Lars¹s blog post some of you may have noticed that a new module called QtCanvas3D became available at https://qt.gitorious.org/qt/qtcanvas3d Just for the sake of Qt Project procedures: This is my +1 vote as a Maintainer for the creation of the new module. From the descriptions given, this seems to complement Qt3D and Qt Quick 2 itself. it would have been preferable to add the new library and Qt Quick items to one of the two existing repositories, but given that new licensing options are being requested, I think it's best to keep them separate. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New module QtCanvas3D now available
Forgot to mention, that the “stable” branch of my three.js port should run out of the box on top of QtCanvas3D, the dev branch is always work in progress more or less so might work, but probably doesn't. You can find the stable branch at: https://github.com/tronlec/three.js/tree/stable Pasi On 21/08/14 09:47, Keränen Pasi pasi.kera...@digia.com wrote: Hi Gunnar, Thanks for the comments, quite a lot to go through, but let me answer the simplest and shortest ones first. The docs say it is an OpenGL-like implementation. True, should say WebGL like, I have a list of differences on API level that I¹ve maintained when implementing the context, but I think we want to fix the TypedArray implementations first and then see if that changes anything on the behaviour level. jsonmodels example uses Enterprise Controls. The example does have option to use the standard controls as well.. Just wanted to show integration with both (how it is the same basically). Do not ever use QMetaMethod::invokeMethod in graphics code. Good catch, it¹s a leftover from when the rendering was done on render thread, it was the only way to ensure the call really happened on that thread. Now it¹s redundant and switching to signal-slots should be done. I'm really not happy about exposing devicePixelRatio in the public JS/QML API of Canvas3DŠ I know, but it¹s the closest I could get to how HTML+WebGL does it and I really want to maintain the compatibility in this case. WebGL spec specifically states, no automatic DPI scaling must be applied, so the devicePixelRatio must be exposed to the JS code that then has to handle it. In the QML files, you say called once on the Scene Graph Render thread²Š Good catch, again leftovers from old implementation.. Can we find some compatibly licensed demo and include that? I¹ve ported the Three.js to this environment, you can find my branch of it at https://github.com/tronlec/three.js and I¹ve ported quite a bit of content on top of that (e.g. http://carvisualizer.plus360degrees.com/threejs/ ). It has been great to verify the functionality and to verify that the porting is as smooth as possible. Unfortunately most really nice content is copyrighted in incompatible way. Any suggestions for demo content with compatible license are most welcome! :) Regards, Pasi On 21/08/14 09:21, Gunnar Sletta gunnar.sle...@jolla.com wrote: Hi Pasi, I'm super happy that we are finally getting support for WebGL in QML, so thanks for picking this up. I have some suggestions for further improvement though: We have a couple of items that implement QSGTextureProvider as an API. It would be really nice if we could use these directly as textures in WebGL. Image, ShaderEffectSource and any item that enables layer.enable: true. Because the Canvas3D runs on the GUI thread this is a bit problematic, of course, but lets talk more about that... I'd really like to see us move this to the proper render thread so we can avoid the context sharing and the FBO blitting. This would allow the to have a mode to run on beforeRendering or on afterRendering as well, and we could have the Canvas3D render directly into the base context of the window. That means we get multisampling even on embedded (which often doesn't have multisampled FBOs) and it saves us an extra blit AND it saves us the Graphics stack potentially stalling if the it is buffering up frames such that a display and a render FBO is not enough to let things run smoothly... This would be an awesome basis for Games with a HUD in QML on top. Running on the render thread also solves the problem of getting a hold of texture providers which would let you put parts of the UI into the scene and allow you to use WebGL to do transition effects.. And it is the only thing that will, in the end, guarantee performance. It does mean that we would have to queue up commands and then replay them on the render thread which creates a problem for glReadPixels, but we can solve that.. It isn't that common a function to call and it is expected to be slow, so we can take a hit on it. We can do something similar to QQuickWindow::grab() and stop the Gui/JS thread until the stuff is rendered, grab the results and then send it back. the QQuickWindow::scheduleRenderJob() API I added in 5.4 might be a good candidate to do something like that (though with a new schedule mode, something like ScheduleAndBlockWithAGLContext. Some smaller stuff: - The docs say it is an OpenGL-like implementation. Isn't it trying to be a WebGL implementation? It would be great if we could link to the official WebGL specification and outline in which areas we are different. - interaction example crashes on MacOS: backtrace http://hastebin.com/ufahatuqud.coffee - jsonmodels example uses Enterprise Controls. I don't think we should have dependencies on commercial only packages in the open source repos. If we do, at least put them somewhere out of sight, like into tests/manual/ or something. It gives a really bad
Re: [Development] New module QtCanvas3D now available
On Thursday 21 August 2014 06:52:06 Keränen Pasi wrote: Hi Thiego, Sorry didn¹t mean to jump the gun. Still a bit new to the Qt process. Just to clarify, the module is not yet part of ³Qt proper². I guess a more correct term for it would have been ³a playground type of preview of a potential new Qt module². Accepting it as new module in Qt proper should of course follow the process and yes, I do agree with your reasoning to keep this separate from Qt3D and Qt Quick 2 for now. The creation of the repository in Gerrit and in qt.gitorious.org requires community approval. Lars had asked for my opinion and support before the announcement, which I gave. The email was just the confirmation of that. -- 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] New module QtCanvas3D now available
yay! :) On 20 Aug 2014, at 15:27, Keränen Pasi pasi.kera...@digia.com wrote: Hi, As part of Lars’s blog post some of you may have noticed that a new module called QtCanvas3D became available at https://qt.gitorious.org/qt/qtcanvas3d QtCanvas3D module is a lightweight implementation of a QML canvas component that allows you to get a 3D context object that you can then use to call WebGL like API from Qt QML JavaScript code. Included examples and documentation should help you get started, just be aware that prior knowledge of similar APIs e.g. OpenGL ES or WebGL is of great help in understanding how the API works. While the API implementation should be complete and should run on all desktop systems, the module is still of preview quality as it relies on non-conformant and slow TypedArray implementation. Also we need to test it more on different systems, especially embedded and mobile devices. Feel free to download, kick the tires and contribute in case you find something missing or not working. Regards, Pasi Keränen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
