Re: [Interest] Creating a DLL with a Qt Project with static Qt

[Hamish Moffatt]

On 01/09/18 01:29, Etienne Sandré-Chardonnal wrote:
> Dear all,
>
> I am reopening an old Windows project which was building a DLL. That 
> DLL is not a Qt plugin, it is a plain DLL with a custom interface.
>
> Now, I am using Qt static (commercial license) and it seems that 
> because of this, qmake generates a static library (.a) instead of a dll.
>
> Is there a way to change that behavior?

If you use

TEMPLATE = lib
CONFIG += dll

then you should get what you want.

(Or CONFIG += plugin if you don't want libxyz.so.1.0.0, just libxyz.so.)

Hamish


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D Framegraphs

[Roland Hughes]

  
  
Can we please quit quoting massive chunks of messages which exceed
the "digest" trigger size so each message comes out as a new digest?
-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
  

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Settings fails persistance on Android

[Paolo Angelelli]

I also have had several issues (mostly persistence issues) with 
Qt.labs.settings.
In the end using QSettings directly seemed to work alright, and so i kept using
that.

A pity since Qt.labs.settings looks much easier to use, but nevertheless..

On Fri, 31 Aug 2018 13:26:05 +0200
René Hansen  wrote:

> Hi,
> 
> 
> I've run into a number of weird cases where properties on a *Settings*
> element doesn't properly persist between launches of an app.
> 
> Initially I used aliasing quite heavily for it's syntactic ease, as per the
> main example from the docs. However, I found that sometimes only part of
> the the properties would properly persist for next launch. I could never
> quite reproduce the issues consistently and it had a sort of
> race-condition'y feel about it. So I gave up an aliases.
> 
> Instead I've opted for a direct one-way load binding on launch and then a
> write-back to the Settings when the app closes down. This seems to work
> correctly regarding value persistence. That is, when it actually works...
> 
> Here's the pickle; Android has two means of closing an application. One is,
> that you can directly exit it via the back button, which triggers a Close
> event on the main window, the other is by suspending the app and then
> "clearing" it out from the list of background processes.
> 
> The former produces a valid result, where properties are properly persisted
> to the *Settings*, the other does not.
> 
> I'm guessing this is because the actual write-back happens on the
> destruction of the Settings element, which is, afaict, never triggered if
> the app is cleared during suspension.
> 
> I've made a futile attempt at manually triggering the write-back, at an
> earlier stage of the shutdown, by connecting the the *application.state*,
> e.g.:
> 
> *  Connections {*
> *target: Qt.application*
> *onStateChanged: {*
> *  switch(Qt.application.state) {*
> *  case Qt.ApplicationActive:*
> *console.log("Qt.ApplicationActive")*
> *break;*
> *  case Qt.ApplicationInactive:*
> *console.log("Qt.ApplicationInactive")*
> *break;*
> *  case Qt.ApplicationSuspended:*
> *console.log("Qt.ApplicationSuspended")*
> 
> *// WRITE STUFF TO SETTINGS HERE*
> 
> *break;*
> *  case Qt.ApplicationHidden:*
> *console.log("Qt.ApplicationHidden")*
> *break;*
> *  }*
> *}*
> *  }*
> 
> However, even by doing it this way, "seemingly" before the app is
> suspended, the values are still not written back at all. Presumably it's
> because of missing destruction trigger mentioned above.
> 
> So, what are my options here if I'd like to use *Settings* here?
> 
> I notice QSettings have a sync
>  method,
> but I don't see anything similar for the QML variant.
> 
> What is the canonical way to solve this problem for Android? Has anyone
> else done this in a practical manner?
> 
> 
> Best regards,
> 
> René Hansen

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D Framegraphs

[Andy]

On Fri, Aug 31, 2018 at 10:30 AM Paul Lemire  wrote:

> Hi Andy,
> Some ideas below :)
>

Thanks a lot Paul - answers inline.


> On 08/31/2018 02:03 PM, Andy wrote:
>
> The contours/silhouetting proved a bit of a leap right now so I backed off
> to look at the offscreen side of it.
>
> I removed the depth pass and am just trying to get a simple frame graph
> working for on-and-off screen capture.
>
> I have the following frame graph (in YAML, but it should be clear):
>
> RenderSurfaceSelector:
>   Viewport:
> ClearBuffers:
>   buffers: ColorDepthBuffer
>   clearColor: "#80faebd7"
>   NoDraw: {}
> CameraSelector:
>   objectName: cameraSelector
>   FrustumCulling: {}
>
> Is that FrustumCulling node the parent of the RenderPassFilter or is it a
> sibling? If it's not the parent of the RenderPassFilter, I looks like it
> would be part of a Branch Viewport -> CameraSelector -> FrustumCulling
> which would be of no use here
>

Yes, I had it as a sibling of the RenderPassFilter. I didn't know where it
went, because QForwardRenderer has it on the QClearBuffers.


>   RenderPassFilter:
> matchAny:
> - FilterKey:
> name: renderingStyle
> value: forward
>   RenderCapture:
> objectName: onScreenCapture
>
> Is the render capture a child of RenderPassFilter or a sibling here? You
> might be getting lucky (or unlucky depends how you see it) because if a
> branch has no RenderPassFilter, by default we select every RenderPasses
> from every Material. So visually it might be working but it's probably not
> what you had in mind.
>

I have it as a sibling. I'll choose... "unlucky" because I thought I
understood why it was working :-)


> What I'm seeing would result in:
>
> Viewport -> ClearBuffers -> NoDraw {} -> clear screen
> Viewport -> CameraSelector -> FrustumCulling {} -> draws to screen with
> FrustumCulling (executing all passes of each material)
> Viewport -> CameraSelector -> RenderPassFilter {} -> draws to screen
> (executing only forward passes)
> Viewport -> CameraSelector -> RenderCapture {} -> capture screen
> (executing all passes of each material)
>

Ah. How do I know which types of node result in drawing? I wouldn't have
expected  FrustumCulling to draw for example - from the docs I thought that
was kind of a "command node" like NoDraw.


> I suspect what you want is rather:
> Viewport -> ClearBuffers -> NoDraw {}
> Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {}
> Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {} ->
> RenderCapture {}
>

> I even think that this could work:
> Viewport -> ClearBuffers -> NoDraw {}
> Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {} ->
> RenderCapture {} as RenderCapture shouldn't prevent from Rendering to
> screen as well
>
>
Even if I take it all the way back to what should be the simplest (I think)
- no FrustumCulling, no capture:

RenderSurfaceSelector:
  Viewport:
ClearBuffers:
  buffers: ColorDepthBuffer
  clearColor: "#80faebd7"
  NoDraw: {}
CameraSelector:
  objectName: cameraSelector
  RenderPassFilter:
matchAny:
- FilterKey:
name: renderingStyle
value: forward

Qt3DRender::QFrameGraphNode::Custom
Qt3DRender::QRenderSurfaceSelector::
Qt3DRender::QViewport::
Qt3DRender::QClearBuffers::
Qt3DRender::QNoDraw::
Qt3DRender::QCameraSelector::cameraSelector
Qt3DRender::QRenderPassFilter::
Qt3DRender::QFilterKey::

I'm getting a cleared screen, no model.

I'm using Qt3DExtras::QPhongMaterial on my entities, so the filter key
should match, right?

Based on what you outlined above, Qt3DExtras::QForwardRenderer doesn't make
sense to me. If QFrustumCulling is doing the drawing, then what's the
purpose of the filter keys on QForwardRenderer since they aren't part of
the QRenderSurfaceSelector branch?

Qt3DExtras::QForwardRenderer::
Qt3DRender::QRenderSurfaceSelector::
Qt3DRender::QViewport::
Qt3DRender::QCameraSelector::
Qt3DRender::QClearBuffers::
Qt3DRender::QFrustumCulling::
Qt3DRender::QFilterKey::

  RenderTargetSelector:
> target:
>   RenderTarget:
> attachments:
> - RenderTargetOutput:
> attachmentPoint: Color0
> texture:
>   Texture2D:
> width: 512
> height: 512
> format: RGBAFormat
>
> You might want to set generateMipMaps to false on the texture
>

Right - I thought they were off by default, but I guess it's better to be
explicit.

ClearBuffers:
>   buffers: ColorDepthBuffer
>   clearColor: "#80faebd7"
>   NoDraw: {}
>
> Looking at it, it does look like it would correctly clear the texture to
> the indicated color.
> Have you 

Re: [Interest] QML Settings fails persistance on Android

[maitai]

I use both, in the backend it is just declared as a QSettings in private
variables. 

QSettings settings; 

And it can access or set settings set or used by the qml part. 

Philippe.

Le 31-08-2018 14:38, René Hansen a écrit :

> I guess you have a QSettings instance instead of using the QML Settings 
> component then?
> 
> /René 
> 
> On Fri, 31 Aug 2018 at 14:35 maitai  wrote: 
> 
> Hi, 
> 
> Here I have a slot in my backend (c++) that is called each time the app goes 
> to background (from override onPause() in java). I do sync() there.
> 
> Philippe. 
> 
> Le 31-08-2018 13:26, René Hansen a écrit : 
> 
> Hi, 
> 
> I've run into a number of weird cases where properties on a SETTINGS element 
> doesn't properly persist between launches of an app. 
> 
> Initially I used aliasing quite heavily for it's syntactic ease, as per the 
> main example from the docs. However, I found that sometimes only part of the 
> the properties would properly persist for next launch. I could never quite 
> reproduce the issues consistently and it had a sort of race-condition'y feel 
> about it. So I gave up an aliases. 
> 
> Instead I've opted for a direct one-way load binding on launch and then a 
> write-back to the Settings when the app closes down. This seems to work 
> correctly regarding value persistence. That is, when it actually works... 
> 
> Here's the pickle; Android has two means of closing an application. One is, 
> that you can directly exit it via the back button, which triggers a Close 
> event on the main window, the other is by suspending the app and then 
> "clearing" it out from the list of background processes. 
> 
> The former produces a valid result, where properties are properly persisted 
> to the SETTINGS, the other does not. 
> 
> I'm guessing this is because the actual write-back happens on the destruction 
> of the Settings element, which is, afaict, never triggered if the app is 
> cleared during suspension. 
> 
> I've made a futile attempt at manually triggering the write-back, at an 
> earlier stage of the shutdown, by connecting the the APPLICATION.STATE, e.g.:
> 
> CONNECTIONS { 
> TARGET: QT.APPLICATION 
> ONSTATECHANGED: { 
> SWITCH(QT.APPLICATION.STATE) { 
> CASE QT.APPLICATIONACTIVE: 
> CONSOLE.LOG("QT.APPLICATIONACTIVE") 
> BREAK; 
> CASE QT.APPLICATIONINACTIVE: 
> CONSOLE.LOG("QT.APPLICATIONINACTIVE") 
> BREAK; 
> CASE QT.APPLICATIONSUSPENDED: 
> CONSOLE.LOG("QT.APPLICATIONSUSPENDED") 
> 
> // WRITE STUFF TO SETTINGS HERE 
> 
> BREAK; 
> CASE QT.APPLICATIONHIDDEN: 
> CONSOLE.LOG("QT.APPLICATIONHIDDEN") 
> BREAK; 
> } 
> } 
> } 
> 
> However, even by doing it this way, "seemingly" before the app is suspended, 
> the values are still not written back at all. Presumably it's because of 
> missing destruction trigger mentioned above. 
> 
> So, what are my options here if I'd like to use SETTINGS here?
> 
> I notice QSettings have a sync [1] method, but I don't see anything similar 
> for the QML variant.
> 
> What is the canonical way to solve this problem for Android? Has anyone else 
> done this in a practical manner? 
> 
> Best regards, 
> 
> René Hansen 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
 

Links:
--
[1] http://doc.qt.io/qt-5/qsettings.html#sync___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Creating a DLL with a Qt Project with static Qt

[Etienne Sandré-Chardonnal]

Dear all,

I am reopening an old Windows project which was building a DLL. That DLL is
not a Qt plugin, it is a plain DLL with a custom interface.

Now, I am using Qt static (commercial license) and it seems that because of
this, qmake generates a static library (.a) instead of a dll.

Is there a way to change that behavior?

Thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D Framegraphs

[Paul Lemire via Interest]

Hi Andy,

Some ideas below :)

On 08/31/2018 02:03 PM, Andy wrote:
> The contours/silhouetting proved a bit of a leap right now so I backed
> off to look at the offscreen side of it.
>
> I removed the depth pass and am just trying to get a simple frame
> graph working for on-and-off screen capture.
>
> I have the following frame graph (in YAML, but it should be clear):
>
> RenderSurfaceSelector:
>   Viewport:
>     ClearBuffers:
>   buffers: ColorDepthBuffer
>   clearColor: "#80faebd7"
>   NoDraw: {}
>     CameraSelector:
>   objectName: cameraSelector
>   FrustumCulling: {}
Is that FrustumCulling node the parent of the RenderPassFilter or is it
a sibling? If it's not the parent of the RenderPassFilter, I looks like
it would be part of a Branch Viewport -> CameraSelector ->
FrustumCulling which would be of no use here

>   RenderPassFilter:
>     matchAny:
>     - FilterKey:
>     name: renderingStyle
>     value: forward
>   RenderCapture:
>     objectName: onScreenCapture
Is the render capture a child of RenderPassFilter or a sibling here? You
might be getting lucky (or unlucky depends how you see it) because if a
branch has no RenderPassFilter, by default we select every RenderPasses
from every Material. So visually it might be working but it's probably
not what you had in mind.

What I'm seeing would result in:

Viewport -> ClearBuffers -> NoDraw {} -> clear screen
Viewport -> CameraSelector -> FrustumCulling {} -> draws to screen with
FrustumCulling (executing all passes of each material)
Viewport -> CameraSelector -> RenderPassFilter {} -> draws to screen
(executing only forward passes)
Viewport -> CameraSelector -> RenderCapture {} -> capture screen
(executing all passes of each material)

I suspect what you want is rather:
Viewport -> ClearBuffers -> NoDraw {}
Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {}
Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {}
-> RenderCapture {}

I even think that this could work:
Viewport -> ClearBuffers -> NoDraw {}
Viewport -> CameraSelector -> FrustumCulling {} -> RenderPassFilter {}
-> RenderCapture {} as RenderCapture shouldn't prevent from Rendering to
screen as well

>   RenderTargetSelector:
>     target:
>   RenderTarget:
>     attachments:
>     - RenderTargetOutput:
>     attachmentPoint: Color0
>     texture:
>   Texture2D:
>     width: 512
>     height: 512
>     format: RGBAFormat
You might want to set generateMipMaps to false on the texture
>     ClearBuffers:
>   buffers: ColorDepthBuffer
>   clearColor: "#80faebd7"
>   NoDraw: {}
Looking at it, it does look like it would correctly clear the texture to
the indicated color.
Have you tried displaying the render target texture by using a PlaneMesh
and a DiffuseMapMaterial?
If you feel adventurous you could try using apitrace to look at the GL
traces and check what's in your texture color attachment
>     RenderPassFilter:
>   matchAny:
>   - FilterKey:
>   name: renderingStyle
>   value: forward
>     RenderCapture:
>   objectName: offScreenCapture
>
> Results of the render captures:
Like the above I think RenderCapture should be a child of
RenderPassFilter here
>
>    onScreenCapture: https://postimg.cc/image/antf2d43h/
>    offScreenCapture: https://postimg.cc/image/e7fcs5z3h/
>
> The onscreen capture is correct - yay a forward renderer!.
>
> 1) Why isn't the offscreen one clearing the background colour using
> ClearBuffers? (Isn't obvious in postimage, but the background is
> transparent.) I tried moving ClearBuffers all over the place, but
> can't get it to work.
>
It looks like your FG is correct regarding the clearing of the
RenderTarget, it would be nice to try to display the texture so that we
can rule out some issue with the RenderCapture operating on a RenderTarget.
> 2) How do I fix the aspect ratio of the offscreen image (assuming I
> want the final image to be 512x512)? Do I need to give it its own
> camera and adjust its aspect ratio somehow?
Yes the easiest would be another Camera which sets its own aspect ratio
(you should be able to forward pretty much all the other properties from
your main camera except the aspect ratio)
>
> Thanks for any guidance!
>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney 
>
>
>
> On Fri, Aug 24, 2018 at 11:24 AM Andy  > wrote:
>
> Paul:
>
> Thank you very much for the detailed responses!
>
> This has given me a lot more to work on/understand.
>
> The ClearBuffers part was very useful for understanding what's
> actually happening. This would be good info to drop into the
> QClearBuffers docs.
>
> I guess I now have to dive into render passes, render 

Re: [Interest] QML Settings fails persistance on Android

[René Hansen]

I guess you have a QSettings instance instead of using the QML Settings
component then?

/René

On Fri, 31 Aug 2018 at 14:35 maitai  wrote:

> Hi,
>
> Here I have a slot in my backend (c++) that is called each time the app
> goes to background (from override onPause() in java). I do sync() there.
>
>
> Philippe.
>
> Le 31-08-2018 13:26, René Hansen a écrit :
>
> Hi,
>
>
> I've run into a number of weird cases where properties on a *Settings*
> element doesn't properly persist between launches of an app.
>
> Initially I used aliasing quite heavily for it's syntactic ease, as per
> the main example from the docs. However, I found that sometimes only part
> of the the properties would properly persist for next launch. I could never
> quite reproduce the issues consistently and it had a sort of
> race-condition'y feel about it. So I gave up an aliases.
>
> Instead I've opted for a direct one-way load binding on launch and then a
> write-back to the Settings when the app closes down. This seems to work
> correctly regarding value persistence. That is, when it actually works...
>
> Here's the pickle; Android has two means of closing an application. One
> is, that you can directly exit it via the back button, which triggers a
> Close event on the main window, the other is by suspending the app and then
> "clearing" it out from the list of background processes.
>
> The former produces a valid result, where properties are properly
> persisted to the *Settings*, the other does not.
>
> I'm guessing this is because the actual write-back happens on the
> destruction of the Settings element, which is, afaict, never triggered if
> the app is cleared during suspension.
>
> I've made a futile attempt at manually triggering the write-back, at an
> earlier stage of the shutdown, by connecting the the *application.state*,
> e.g.:
>
> *  Connections {*
> *target: Qt.application*
> *onStateChanged: {*
> *  switch(Qt.application.state) {*
> *  case Qt.ApplicationActive:*
> *console.log("Qt.ApplicationActive")*
> *break;*
> *  case Qt.ApplicationInactive:*
> *console.log("Qt.ApplicationInactive")*
> *break;*
> *  case Qt.ApplicationSuspended:*
> *console.log("Qt.ApplicationSuspended")*
>
> *// WRITE STUFF TO SETTINGS HERE*
>
> *break;*
> *  case Qt.ApplicationHidden:*
> *console.log("Qt.ApplicationHidden")*
> *break;*
> *  }*
> *}*
> *  }*
>
> However, even by doing it this way, "seemingly" before the app is
> suspended, the values are still not written back at all. Presumably it's
> because of missing destruction trigger mentioned above.
>
> So, what are my options here if I'd like to use *Settings* here?
>
> I notice QSettings have a sync  
> method,
> but I don't see anything similar for the QML variant.
>
> What is the canonical way to solve this problem for Android? Has anyone
> else done this in a practical manner?
>
>
> Best regards,
>
> René Hansen
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QML Settings fails persistance on Android

[maitai]

Hi, 

Here I have a slot in my backend (c++) that is called each time the app
goes to background (from override onPause() in java). I do sync() there.

Philippe. 

Le 31-08-2018 13:26, René Hansen a écrit :

> Hi, 
> 
> I've run into a number of weird cases where properties on a SETTINGS element 
> doesn't properly persist between launches of an app. 
> 
> Initially I used aliasing quite heavily for it's syntactic ease, as per the 
> main example from the docs. However, I found that sometimes only part of the 
> the properties would properly persist for next launch. I could never quite 
> reproduce the issues consistently and it had a sort of race-condition'y feel 
> about it. So I gave up an aliases. 
> 
> Instead I've opted for a direct one-way load binding on launch and then a 
> write-back to the Settings when the app closes down. This seems to work 
> correctly regarding value persistence. That is, when it actually works... 
> 
> Here's the pickle; Android has two means of closing an application. One is, 
> that you can directly exit it via the back button, which triggers a Close 
> event on the main window, the other is by suspending the app and then 
> "clearing" it out from the list of background processes. 
> 
> The former produces a valid result, where properties are properly persisted 
> to the SETTINGS, the other does not. 
> 
> I'm guessing this is because the actual write-back happens on the destruction 
> of the Settings element, which is, afaict, never triggered if the app is 
> cleared during suspension. 
> 
> I've made a futile attempt at manually triggering the write-back, at an 
> earlier stage of the shutdown, by connecting the the APPLICATION.STATE, e.g.:
> 
> CONNECTIONS { 
> TARGET: QT.APPLICATION 
> ONSTATECHANGED: { 
> SWITCH(QT.APPLICATION.STATE) { 
> CASE QT.APPLICATIONACTIVE: 
> CONSOLE.LOG("QT.APPLICATIONACTIVE") 
> BREAK; 
> CASE QT.APPLICATIONINACTIVE: 
> CONSOLE.LOG("QT.APPLICATIONINACTIVE") 
> BREAK; 
> CASE QT.APPLICATIONSUSPENDED: 
> CONSOLE.LOG("QT.APPLICATIONSUSPENDED") 
> 
> // WRITE STUFF TO SETTINGS HERE 
> 
> BREAK; 
> CASE QT.APPLICATIONHIDDEN: 
> CONSOLE.LOG("QT.APPLICATIONHIDDEN") 
> BREAK; 
> } 
> } 
> } 
> 
> However, even by doing it this way, "seemingly" before the app is suspended, 
> the values are still not written back at all. Presumably it's because of 
> missing destruction trigger mentioned above. 
> 
> So, what are my options here if I'd like to use SETTINGS here?
> 
> I notice QSettings have a sync [1] method, but I don't see anything similar 
> for the QML variant.
> 
> What is the canonical way to solve this problem for Android? Has anyone else 
> done this in a practical manner? 
> 
> Best regards, 
> 
> René Hansen 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
 

Links:
--
[1] http://doc.qt.io/qt-5/qsettings.html#sync___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt3D Framegraphs

[Andy]

The contours/silhouetting proved a bit of a leap right now so I backed off
to look at the offscreen side of it.

I removed the depth pass and am just trying to get a simple frame graph
working for on-and-off screen capture.

I have the following frame graph (in YAML, but it should be clear):

RenderSurfaceSelector:
  Viewport:
ClearBuffers:
  buffers: ColorDepthBuffer
  clearColor: "#80faebd7"
  NoDraw: {}
CameraSelector:
  objectName: cameraSelector
  FrustumCulling: {}
  RenderPassFilter:
matchAny:
- FilterKey:
name: renderingStyle
value: forward
  RenderCapture:
objectName: onScreenCapture
  RenderTargetSelector:
target:
  RenderTarget:
attachments:
- RenderTargetOutput:
attachmentPoint: Color0
texture:
  Texture2D:
width: 512
height: 512
format: RGBAFormat
ClearBuffers:
  buffers: ColorDepthBuffer
  clearColor: "#80faebd7"
  NoDraw: {}
RenderPassFilter:
  matchAny:
  - FilterKey:
  name: renderingStyle
  value: forward
RenderCapture:
  objectName: offScreenCapture

Results of the render captures:

   onScreenCapture: https://postimg.cc/image/antf2d43h/
   offScreenCapture: https://postimg.cc/image/e7fcs5z3h/

The onscreen capture is correct - yay a forward renderer!.

1) Why isn't the offscreen one clearing the background colour using
ClearBuffers? (Isn't obvious in postimage, but the background is
transparent.) I tried moving ClearBuffers all over the place, but can't get
it to work.

2) How do I fix the aspect ratio of the offscreen image (assuming I want
the final image to be 512x512)? Do I need to give it its own camera and
adjust its aspect ratio somehow?

Thanks for any guidance!

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 



On Fri, Aug 24, 2018 at 11:24 AM Andy  wrote:

> Paul:
>
> Thank you very much for the detailed responses!
>
> This has given me a lot more to work on/understand.
>
> The ClearBuffers part was very useful for understanding what's actually
> happening. This would be good info to drop into the QClearBuffers docs.
>
> I guess I now have to dive into render passes, render states, and
> materials now. :-)
>
> I also have a better appreciation for why most examples are QML - writing
> these in C++ is time consuming and error-prone. I've written a little
> (partially working) experiment to specify them in YAML so I don't have to
> pull in all the QML stuff just for defining my framegraph(s). I may
> continue down that road.
>
> Have there been any thoughts/discussions on providing a non-QML way to
> declare these? Could be useful for tooling (Qt Creator plugin for defining
> them visually?) as well.
>
> Thanks again for taking the time to go through this.
>
> ---
> Andy Maloney  //  https://asmaloney.com
> twitter ~ @asmaloney 
>
>
>
> On Tue, Aug 21, 2018 at 9:10 AM Paul Lemire  wrote:
>
>>
>> On 08/21/2018 01:54 PM, Andy wrote:
>>
>> Thank you so much Paul!
>>
>> That gives me something to start working on/pick apart. I see now how
>> onscreen vs. offscreen works and can concentrate on getting the onscreen
>> working the way I want first since they are very similar.
>>
>> 1) "I assume you want to fill the depth buffer with a simple shader
>> right?"
>>
>> I think so? Ultimately I want to experiment with a cel-shaded scene, but
>> for now I'd be happy with adding some black contours on my entities using
>> depth - slightly thicker lines closer to the camera, thinner farther away.
>> Is this the right setup for that?
>>
>>
>> Hmm that's not necessarily what I pictured. Usually a render pass where
>> the depth buffer is filled is used as an optimization technique so that 1)
>> You draw your scene with a very simple shader to fill the depth buffer 2)
>> You draw you scene again using a more complex shader but you then take
>> advantage of the fact that the GPU will only execute the fragment shader
>> for fragment whose depth is equal to what is stored in the depth buffer.
>>
>> If you want to draw contours (which is usually referred as silhouetting)
>> the technique is different. Meshes are composed of triangles which are
>> specified in a given winding order (order in which the triangles vertices
>> are specified, either clockwise or counterclockwise). That winding order
>> can be used at draw time to distinguish between triangles which are facing
>> the camera and triangles which are backfacing the camera. (Usually another
>> optimization technique is to not draw backfacing triangles a.k.a backface
>> culling).
>>
>> A possible silhouetting technique implementation can be to:
>> 1) draw only the back faces of the mesh (slightly enlarged) and with
>> depth writing into the 

[Interest] QML Settings fails persistance on Android

[René Hansen]

Hi,


I've run into a number of weird cases where properties on a *Settings*
element doesn't properly persist between launches of an app.

Initially I used aliasing quite heavily for it's syntactic ease, as per the
main example from the docs. However, I found that sometimes only part of
the the properties would properly persist for next launch. I could never
quite reproduce the issues consistently and it had a sort of
race-condition'y feel about it. So I gave up an aliases.

Instead I've opted for a direct one-way load binding on launch and then a
write-back to the Settings when the app closes down. This seems to work
correctly regarding value persistence. That is, when it actually works...

Here's the pickle; Android has two means of closing an application. One is,
that you can directly exit it via the back button, which triggers a Close
event on the main window, the other is by suspending the app and then
"clearing" it out from the list of background processes.

The former produces a valid result, where properties are properly persisted
to the *Settings*, the other does not.

I'm guessing this is because the actual write-back happens on the
destruction of the Settings element, which is, afaict, never triggered if
the app is cleared during suspension.

I've made a futile attempt at manually triggering the write-back, at an
earlier stage of the shutdown, by connecting the the *application.state*,
e.g.:

*  Connections {*
*target: Qt.application*
*onStateChanged: {*
*  switch(Qt.application.state) {*
*  case Qt.ApplicationActive:*
*console.log("Qt.ApplicationActive")*
*break;*
*  case Qt.ApplicationInactive:*
*console.log("Qt.ApplicationInactive")*
*break;*
*  case Qt.ApplicationSuspended:*
*console.log("Qt.ApplicationSuspended")*

*// WRITE STUFF TO SETTINGS HERE*

*break;*
*  case Qt.ApplicationHidden:*
*console.log("Qt.ApplicationHidden")*
*break;*
*  }*
*}*
*  }*

However, even by doing it this way, "seemingly" before the app is
suspended, the values are still not written back at all. Presumably it's
because of missing destruction trigger mentioned above.

So, what are my options here if I'd like to use *Settings* here?

I notice QSettings have a sync
 method,
but I don't see anything similar for the QML variant.

What is the canonical way to solve this problem for Android? Has anyone
else done this in a practical manner?


Best regards,

René Hansen
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Barcelona Qt meetup September 2018

[Davide Coppola]

Hi,
next Thursday the 6th of September we will be running a new Qt meetup in
Barcelona where Alexandra Betouni will give an introduction about the Qt
Automotive Suite.

To attend please register here:
https://www.meetup.com/Barcelona-Qt-Meetup/events/252896049/


After the presentation there will be a networking session with free drinks.

See you soon

-- 
*Davide Coppola*

*website:* http://www.davidecoppola.com
*blog:* http://blog.davidecoppola.com
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest