[Development] Adding new third party component three.js to Qt?

[Keränen Pasi]

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"
<perezmeyer at 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/