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 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

Reply via email to