[Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes)
Hi, As Lars mentioned in his email on KDE Free Qt foundation agreement and changes, we’re pushing source of Qt Charts and Qt DataVisualization to codereview. I’d like to propose these two modules to be taken as part of Qt add-on modules, they have been part of commercial Qt releases for some time now. And I’d like to propose Tomi Korpipää to be named as the maintainer of Qt DataVisualization, Tomi has been one of the key developers in the development of DataVisualization from the beginning. Also I’d like to propose Miikka Heikkinen as maintainer for Qt Charts, Miikka has a long history with the module and has recently started adding OpenGL optimisations to some of the parts. Regards, Pasi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS-UP: Qt 5.6 feature freeze and branching coming
Hi, Canvas3D has a WIP branch that is now quite stable and should be merged to dev before FF. The Canvas3D WIP branch is rewrite of some of the parts to move rendering to render thread, allow use of Qt Quick items as texture sources etc. so I'd rather do the WIP branch merge after any mass merges are done from 5.5 branch. Is there such a mass merge in the plans? Regards, Pasi From: Heikkinen Jani jani.heikki...@theqtcompany.commailto:jani.heikki...@theqtcompany.com Date: Monday 3 August 2015 13:55 To: development@qt-project.orgmailto:development@qt-project.org development@qt-project.orgmailto:development@qt-project.org Cc: releas...@qt-project.orgmailto:releas...@qt-project.org releas...@qt-project.orgmailto:releas...@qt-project.org Subject: [Development] HEADS-UP: Qt 5.6 feature freeze and branching coming Hi all, According to Qt 5.6 schedule (http://wiki.qt.io/Qt-5.6-release) feature freeze branching from 'dev' to '5.6' should happen next Monday (10.8.2015). How it seems, are we ready for FF after a week? - Are all new modules in 'dev' already now? should be, see http://lists.qt-project.org/pipermail/development/2015-June/021809.html - Are all mandatory new features in 'dev' now or coming in within a week? - Are new modules features fulfilling FF criteria, see http://wiki.qt.io/Qt5_feature_freeze (* List of new features in Qt 5.6 seems to be quite short, see http://wiki.qt.io/New_Features_in_Qt_5.6 so it should be quite easy to do the FF ;) Or the page needs some updates from feature/module owners...) Is there something which prevents us to proceed as planned? Is new CI system working well enough etc? Is Qt5.git update working ok in dev? I notice from https://codereview.qt-project.org/#/c/121238/ : Simon Hausmann Jul 24 5:41 AM Patch Set 31: Code-Review-2 Updates will be different br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes fail to integrate due to unexpected errors
Hi, Same issue with [2] in qtcanvas3d as well, several tries on Friday and over the weekend have failed due problems with CI. [2] https://codereview.qt-project.org/#/c/104158/ Regards, Pasi On 02/02/15 03:14, Aaron McCarthy mccarthy.aa...@gmail.com wrote: Hi, Changes, such as [1], to the qtlocation repository have been failing to integrate for the last few days with errors similar to: An unexpected error occurred, most likely due to no fault in the tested code itself :( Please point some CI administrator towards this problem. Meanwhile, it may be worthwhile to attempt the build again. `git clone qtgitreadonly:qt/qtqa.git _qtqa_latest' exited with code 128 at _testconfig/test.pl line 1103. Build log: http://testresults.qt-project.org/ci/QtLocation_dev_Integration/build_0034 1/win32-mingw491_developer-build_qtlibinfix_Windows_7/log.txt.gz Can a CI administrator please investigate the issue. [1] https://codereview.qt-project.org/101972 Cheers, -- Aaron McCarthy ___ 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] Adding new third party component three.js to Qt?
Hi everyone, So far it seems there has been some positive answers from the community, but the distribution packaging side seems to have most comments against inclusion of the three.js library or at least have comments on HOW it should be included. Sorry, I¹m dropping out of the ³qtchooser² thread, it¹s going way over my understanding of packaging related issues, I¹m a graphics guy and will let the more capable people from our releasing side comment on that. But out of curiosity, can I ask for a show of hands on which distributions currently include the 100% JavaScript three.js based 3D scene graph library in them OR are expecting to do so in the future? Just to see how much impact are we talking about if we decide to include the library to cater for those users that do seem to want a ready ported and verified to work solution within their Qt SDK for their Canvas3D related scene graph needs (perhaps by taking the approach Louai suggested earlier to allow for the eventuality that some distribution wants to include their chosen version of three.js in it). Regards, Pasi On 19/01/15 13:27, Keränen Pasi pasi.kera...@theqtcompany.com wrote: Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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] Adding new third party component three.js to Qt?
Hi Thiago (and Lars), Surely we can include a minified version that gets bundled with your app when you e.g. use a new project wizard to create a Canvas3D project with three.js? No need to have any larger than necessary files there? Already the new project wizard freezes up to around 20-40 seconds (beachballing Qt Creator on my Mac while it does it) when you create a new project as it¹s copying the 800k three.js file, I¹d like to cut down that time as much as possible. But if people really want to hack around with the three.js port I¹d expect them to use the original source files (each class in separate .js file) as it¹s a bit unwieldy to edit that ~800k sourcefile (trust me, been there done that bunch of times when trying to figure out a bug in it). It¹s a lot nicer to edit the separate files for each class and then build the big source file after you¹ve done the modifications.. So I¹m thinking we then should actually include the separate source files and the build script for that as well? And offer the minified version (once it builds and works with V4VM that is) as ³pre built binary² version as well. Regards, Pasi On 08/01/15 19:05, Thiago Macieira thiago.macie...@intel.com wrote: On Thursday 08 January 2015 12:47:04 Keränen Pasi wrote: Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Minification is to be done by the buildsystem. We need to ship the source in the format that developers prefer to make modifications to. -- 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] Adding new third party component three.js to Qt?
Hi Kevin and Lisandro, I have zero experience with distribution packaging and the problems therein so sorry if I’m a bit lost here. Thank you Kevin for the links you sent, I found them informative. I followed the Packaging:JavaScript link and it states Please note that this section really only applies to JavaScript libraries intended for use on the web”. Canvas3D and three.js port on top of it are NOT meant to be used on the web, they are both meant to be used within QtQuick/QML environment, so running locally as part of your native code (or pure QtQuick) application. I also read through the Packaging:No_Bundled_Libraries link. I can see the points made in there, but there is also a good reason why we want to bundle the three.js together with certain version of Qt and Canvas3D. We want to deliver a library that we know has been tested together with the V4 VM and the Canvas3D and we know it should run smoothly there. And by doing this we add value to our customers. Regarding one of the points made in that document on forks. Yes, at the moment this port from HTML to QtQuick is a fork of the official three.js library and lives right next to it in Github. But as I said I’m hoping we can reduce the delta we have by doing some additional work on the V4VM and on the Canvas3D. And perhaps if the remaining HTML vs. QML delta is in only few places and is minimal, we can then persuade the maintainers of three.js to re-design those few parts to make upstreaming possible with a clean design. As I said the discussion about doing the upstreaming to three.js hasn’t been started. The simple reason being I want us to have done the best we can before we start nudging them and asking if they’d be interested in our changes that make their library on top of Qt Quick. That way the discussion is going to be easier and the amount of work needed to do the upstreaming is going to be minimal. I don’t want to start that discussions by saying “I’d like you to remove the use of self executing functions in this class just because for some reason in this particular case our VM just doesn’t handle it very well..”. I realised I didn’t mention timeline for this adding of three.js at all. My own estimate is that we could be able to only ship a few examples with Canvas3D that will use three.js as part of the examples in Qt 5.5, not add three.js as part of Qt quite at that point due to various reasons. One being we will not have the time to test it properly by that time. We’ll need to do the homework on some of the issues we have before we can add three.js as part of Qt officially (meaning you can then just say import blah in your QML to get three.js included). My own estimate/guess is that could be around Qt 5.6 and I’d hope that before this point we could have the delta so minimal that we could reasonably start the discussion with three.js maintaineres about upstreaming the changes we really, really need. Not including changes we have today just because of issues in our own code. Regards, Pasi On 14/01/15 04:06, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote: On Tuesday 13 January 2015 03:20:38 Kevin Kofler wrote: Sorry for raining on your parade, but… Keränen Pasi wrote: I¹d like to open the discussion on including the three library as part of Qt 5.6 and onwards. Mainly because this would give our users a better experience if we¹d bundle the right, tested version of Three.js together with the Qt version it was tested on. … we distribution packagers REALLY hate bundled libraries… Same here. The library will for now at least need some porting effort to make it run on top of Canvas3D as there are some HTML depencencies that need to be handled, plus V4VM has a few quirks that need to be accounted for. Hopefully some of the V4VM quirks are bugs and will be fixed in due time, but the HTML dependencies do remain. And my current experience with graphics APIs is that you want to test the whole stack together. If we e.g. add support for new extensions in Canvas3D, that can activate new codepaths in Three.js that again need testing and possibly new Qt specific delta must be added to the three.js for those parts. … and especially FORKED bundled libraries (where we stand no realistic chance of actually unbundling them). I couldn't agree more. And also thanks Thiago for pointing that the lib should be minimized by the build system, else we wouldn't be able to ship it, even in it's embedded form. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi Mark,
thank you for bringing this to my attention!
I hadn't noticed that the Qt 5.4 install doesn't have the documentation for
QtCanvas3D under Docs, while it does have documentation for QtWebView tech
preview. We're planning to do a Tech Preview 2 with Qt 5.4.1 as I've fixed
quite a few bugs that will be visible to most users of Canvas3D since Tech
Preview 1. I'll investigate why the docs are not building and try to sort it
out for 5.4.1 release.
Meanwhile you should be able to build the documentation yourself from the
QtCanvas3D sources with make docs. As I said, best option at this point is to
get the latest from https://codereview.qt-project.org/qt/qtcanvas3d as there
are quite a few bug fixes done since TP1.
Regards,
Pasi
From: development-bounces+pasi.keranen=theqtcompany@qt-project.org
development-bounces+pasi.keranen=theqtcompany@qt-project.org on behalf of
Mark Gaiser mark...@gmail.com
Sent: Friday, January 9, 2015 5:01 PM
To: development@qt-project.org
Subject: Re: [Development] Adding new third party component three.js to Qt?
On Fri, Jan 9, 2015 at 3:39 PM, Keränen Pasi
pasi.kera...@theqtcompany.commailto:pasi.kera...@theqtcompany.com wrote:
Hi Louai,
The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.
* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.
* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.
* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.
* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value) { this._x = value; this.onChangeCallback(); }
* Must be rewritten with the (older?) syntax of:
this.__defineGetter__(x, function(){return this._x;});
this.__defineSetter__(x, function(value){this._x =
value;this.onChangeCallback();});
* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.
That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.
Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.
Regards,
Pasi
On 08/01/15 12:54, Al-Khanji Louai
louai.al-kha...@theqtcompany.commailto:louai.al-kha...@theqtcompany.com
wrote:
On Wednesday 7. January 2015 06.03.14tel:2015%2006.03.14 Keränen Pasi
wrote:
Hi,
I¹d like to open the discussion on including
Re: [Development] Adding new third party component three.js to Qt?
Hi Louai,
The changes required to the library were originally quite large. But
thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
wrapper classes to make e.g. Image loading look and smell like in HTML
land, the delta has been getting smaller and smaller. Here is a pretty
complete list based on quick compare between the R69 original three.js and
the Canvas3D port of the R69 release of three.js. There might be something
I’m forgetting to mention here. But as I said the delta has been getting
smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
some delta always as QtQuick is not HTML.
* We don’t have performance timers in Qt Quick JS, so the Clock class must
be modified to not use those.
* In some files the class is declared with syntax of ( function (THREE) {
blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
executing functions don’t seem to work, V4VM just refuses to load the
file. I haven’t been able to replicate this behaviour with a small
example, so probably it’s relates to some complex situation arising when
loading a large JavaScript file OR then there is some minute detail in
that self executing function that I can’t spot.
* Resizing of images has to be modified as that is usually done with HTML
trickery that doesn’t work at the moment with Canvas3D.
* Accessor functions defined in prototypes with:
get x() { return this._x },
set x(value) { this._x = value; this.onChangeCallback(); }
* Must be rewritten with the (older?) syntax of:
this.__defineGetter__(x, function(){return this._x;});
this.__defineSetter__(x, function(value){this._x =
value;this.onChangeCallback();});
* Canvas3DRenderer is new code, ported from WebGL. Main differences are to
do with initialization differences between Canvas3D and WebGL. Handling of
some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
(should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
place and function overloading should work). And I’ve wanted to support
the logging features of Canvas3D objects, by setting the .name attribute
of some objects so that when you turn on logging you can see what
UniformAttribute, what Shader3D object you are looking at in the logs..
Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
name in the renderer causes V4VM not to load the file, but again a minimal
example of this doesn’t have this problem so can’t replicate it). Again,
the delta should get smaller with WebGLRenderer, but I’d expect there to
always be some delta.
That is all the delta I can list quickly, if you are interested in details
just get the R69 release from three.js git and the stable branch of
QtCanvas3D port and do a detailed compare of those.
Reagrding this delta I’ve thought a bit how to reorganise the delta so
that it could live in a separate folder inside three.js. If I can make
that happen, then maybe it would be possible to get these few changes in
to three.js upstream and make it possible to always use the latest from
there as well if one so wishes. But that will require a bit more work on
V4VM I think before we’re there. E.g. Add support for binary file loading
with XMLHttpRequest and track down why those few anomalies occur when
loading self executing functions declared in the manner they are in
three.js so that the upstream code should run as much as possible
unmodified on top of Canvas3D with just the few changes we need in place.
Regards,
Pasi
On 08/01/15 12:54, Al-Khanji Louai louai.al-kha...@theqtcompany.com
wrote:
On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
Hi,
I¹d like to open the discussion on including the three library as
part of
Qt 5.6 and onwards. Mainly because this would give our users a better
experience if we¹d bundle the right, tested version of Three.js
together
with the Qt version it was tested on.
I¹ve been pushing the Qt Canvas3D component onwards and timewise it
should
be landing to Qt 5.5 release. The WebGL-like API (non-conformance
tested)
it offers is very low level and most users will not like to work on
that
level. To that end I¹ve ported the WebGL based Three.js scenegraph
library
available at http://threejs.org on top of Canvas3D. You can find the
latest version from master branch at
https://github.com/tronlec/three.js
The reason for picking this particular library over others are:
* It¹s one of the most active WebGL scene graph projects out there.
* It¹s well done, with examples, API documentation etc.
* It has excellent support form community in the form of tutorials,
websites, discussion forums etc.
* It is available under permissive MIT license:
https://github.com/mrdoob/three.js/blob/master/LICENSE
In Qt 5.5 we¹ll include a few examples that will have this library as
part
of the examples.
The library will for now at least need some porting effort to make it
run
on top of Canvas3D as there are some HTML
Re: [Development] Adding new third party component three.js to Qt?
Size without minification is 824kBytes. Unfortunately minification currently fails due to the placeholder TypedArray wrappers in Qt Canvas3D. Pasi On 08/01/15 12:52, Hausmann Simon simon.hausm...@theqtcompany.com wrote: On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote: Hi, I¹d like to open the discussion on including the three library as part of Qt 5.6 and onwards. Mainly because this would give our users a better experience if we¹d bundle the right, tested version of Three.js together with the Qt version it was tested on. I¹ve been pushing the Qt Canvas3D component onwards and timewise it should be landing to Qt 5.5 release. The WebGL-like API (non-conformance tested) it offers is very low level and most users will not like to work on that level. To that end I¹ve ported the WebGL based Three.js scenegraph library available at http://threejs.org on top of Canvas3D. You can find the latest version from master branch at https://github.com/tronlec/three.js The reason for picking this particular library over others are: * It¹s one of the most active WebGL scene graph projects out there. * It¹s well done, with examples, API documentation etc. * It has excellent support form community in the form of tutorials, websites, discussion forums etc. * It is available under permissive MIT license: https://github.com/mrdoob/three.js/blob/master/LICENSE In Qt 5.5 we¹ll include a few examples that will have this library as part of the examples. The library will for now at least need some porting effort to make it run on top of Canvas3D as there are some HTML depencencies that need to be handled, plus V4VM has a few quirks that need to be accounted for. Hopefully some of the V4VM quirks are bugs and will be fixed in due time, but the HTML dependencies do remain. And my current experience with graphics APIs is that you want to test the whole stack together. If we e.g. add support for new extensions in Canvas3D, that can activate new codepaths in Three.js that again need testing and possibly new Qt specific delta must be added to the three.js for those parts. Comments? Thoughts? Sounds like a good idea to me. What's the size (lines of code) that we are talking about here? Is it just one big minified .js file? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Adding new third party component three.js to Qt?
Hi, I¹d like to open the discussion on including the three library as part of Qt 5.6 and onwards. Mainly because this would give our users a better experience if we¹d bundle the right, tested version of Three.js together with the Qt version it was tested on. I¹ve been pushing the Qt Canvas3D component onwards and timewise it should be landing to Qt 5.5 release. The WebGL-like API (non-conformance tested) it offers is very low level and most users will not like to work on that level. To that end I¹ve ported the WebGL based Three.js scenegraph library available at http://threejs.org on top of Canvas3D. You can find the latest version from master branch at https://github.com/tronlec/three.js The reason for picking this particular library over others are: * It¹s one of the most active WebGL scene graph projects out there. * It¹s well done, with examples, API documentation etc. * It has excellent support form community in the form of tutorials, websites, discussion forums etc. * It is available under permissive MIT license: https://github.com/mrdoob/three.js/blob/master/LICENSE In Qt 5.5 we¹ll include a few examples that will have this library as part of the examples. The library will for now at least need some porting effort to make it run on top of Canvas3D as there are some HTML depencencies that need to be handled, plus V4VM has a few quirks that need to be accounted for. Hopefully some of the V4VM quirks are bugs and will be fixed in due time, but the HTML dependencies do remain. And my current experience with graphics APIs is that you want to test the whole stack together. If we e.g. add support for new extensions in Canvas3D, that can activate new codepaths in Three.js that again need testing and possibly new Qt specific delta must be added to the three.js for those parts. Comments? Thoughts? Regards, Pasi Keränen Software Specialist The Qt Company http://www.qt.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New module QtCanvas3D now available
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
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
