Re: [Interest] [Qt3D] any way to synchronize main thread with render thread ?

2018-01-17 Thread david crémoux
My mistake: I'm not on OnDemand render policy. On 18.01.2018 10:04, david crémoux wrote: Hello, While using Qt3D I'm trying to separate as much as possible the scene, rendering, and render window/widget. I'm not using Qt3DWindow, I'm using my own widget/surface. The thing is, when I'm

[Interest] [Qt3D] any way to synchronize main thread with render thread ?

2018-01-17 Thread david crémoux
Hello, While using Qt3D I'm trying to separate as much as possible the scene, rendering, and render window/widget. I'm not using Qt3DWindow, I'm using my own widget/surface. The thing is, when I'm deleting my widget, I'm not deleting everything like in Qt3DWindow (scene, rendering, aspect,

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Jean-Michaël Celerier
I propose the following motion: directly import the whole of github & sourceforge into the Qt project. After all why shouldn't every piece of code in the universe be part of Qt, released at a perfect six-month cadence ? This way, every project in the world will be able to access the "private" Qt

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Thiago Macieira
On Wednesday, 17 January 2018 10:27:43 PST Uwe Rathmann wrote: > On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > > It is just sharing code. The important difference is that both modules > > are developed at the same time and released at the same time, by the > > same team. > > Yes of

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Konstantin Tokarev
17.01.2018, 21:30, "Uwe Rathmann" : > On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > >>  It is just sharing code. The important difference is that both modules >>  are developed at the same time and released at the same time, by the >>  same team. > > Yes

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > It is just sharing code. The important difference is that both modules > are developed at the same time and released at the same time, by the > same team. Yes of course, but my project is developed at a different time, released at a

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Thiago Macieira
On Wednesday, 17 January 2018 03:24:26 PST Uwe Rathmann wrote: > On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote: > > Why do you need private headers in the first place? > > For the same reason, why a module like QuickControls 2 is using private > headers of Quick Core. It is just

Re: [Interest] Multiple QNetworkAccessManagers for a single app

2018-01-17 Thread Konstantin Tokarev
17.01.2018, 16:12, "Richard Moore" : > On 11 January 2018 at 18:41, Tom Isaacson wrote: >> But is it a performance issue, a potential threading problem, what? >> >> We have a large codebase and this practice hasn't been followed, I'm >> wondering what the

Re: [Interest] Multiple QNetworkAccessManagers for a single app

2018-01-17 Thread Richard Moore
On 11 January 2018 at 18:41, Tom Isaacson wrote: > But is it a performance issue, a potential threading problem, what? > > We have a large codebase and this practice hasn't been followed, I'm > wondering what the potential impact is and whether it's worth fixing. > A

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote: > Why do you need private headers in the first place? For the same reason, why a module like QuickControls 2 is using private headers of Quick Core. The qskinny project is about creating a C++ framework ( QML is only optional )

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Christian Gagneraud
On 17 January 2018 at 21:32, Uwe Rathmann wrote: > On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote: > > This how I do it ( see https://github.com/uwerat/qskinny ): > > QT += quick quick-private > CONFIG += no_private_qt_headers_warning > > To get rid of warnings

Re: [Interest] Qt3D: Correct way of using QBuffer and a compute shader

2018-01-17 Thread Michael Sué
Hi, I use attributes, like positionAttributes (for the vertices) and normalAttributes (for the normal vectors). Attributes contain the buffer, datatype and size information. But I think this is not essential. The buffer for vertices and normal are usual one big array, used in two blocks:

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote: This how I do it ( see https://github.com/uwerat/qskinny ): QT += quick quick-private CONFIG += no_private_qt_headers_warning To get rid of warnings from Qt headers, when doing pedantic checks I also have the following lines: linux {

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Mitch Curtis
In qtquickcontrols2.git [1] it’s linked to like this: QT_PRIVATE += quick-private I think QT += quick-private also works.. not sure what the difference is. [1] http://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/quicktemplates2.pro#n6 On 1/16/18, 4:43 PM, "Interest on