[Development] New module QtCanvas3D now available

[Keränen Pasi]

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.sletta at 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 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.Keranen at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>