date:20171212

Re: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound.

2017-12-12 Thread Liang Qi

https://codereview.qt-project.org/#/c/214045/ was merged. dev is fixed now.

— Liang

> On 11 Dec 2017, at 12:22, Liang Qi  wrote:
> 
> dev is blocked by "Module "" () Failed to provision template 
> 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change:
> https://codereview.qt-project.org/#/c/214045/

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Module "" () : on QtRemoteObjects

2017-12-12 Thread Alexandru Croitor

Hi,

Afaik the fix was applied to 5.9 and 5.10 branches, whereas your change targets 
dev. Restaging will not help at the moment.

On Dec 12, 2017, at 19:38, Stottlemyer, Brett (B.S.) 
> wrote:

Hi list,

I saw some traffic on QtBase showing the above error staging from Gerrit (which 
I thought was fixed).  I’m seeing the same thing on the Qt Remote Objects 
module.  Is this expected?  Is there anything trick other than retry?

The specific change is https://codereview.qt-project.org/#/c/213340/

Thanks,
Brett
___
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] Module "" () : on QtRemoteObjects

2017-12-12 Thread Stottlemyer, Brett (B.S.)

Hi list,

I saw some traffic on QtBase showing the above error staging from Gerrit (which 
I thought was fixed).  I'm seeing the same thing on the Qt Remote Objects 
module.  Is this expected?  Is there anything trick other than retry?

The specific change is https://codereview.qt-project.org/#/c/213340/

Thanks,
Brett
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] COIN failures on dev

2017-12-12 Thread Adam Treat

This was apparently the result of a miscommunication and no force 
pushing is contemplated.

On 12/12/2017 01:24 PM, Tuukka Turunen wrote:

Hi,

Force pushing of what? Of course in a situation where nothing else is 
possible, we need to have a way to unblock CI by forced push. But we 
are not pushing other than really mandatory fixes in bypassing the CI.

It is very unfortunate that dev has been broken for a while, but work 
is ongoing to unblock it.

Yours,

    Tuukka

*From: *Development 
 on behalf of 
Adam Treat 

*Date: *Tuesday, 12 December 2017 at 13.10
*To: *Simon Hausmann , 
"development@qt-project.org" 

*Subject: *Re: [Development] COIN failures on dev

Ah, so last successful integration on qt5 super module was nearly a 
month ago?? 11/172017

Now, what I was really after was last generally unsuccessful 
integration to see how all the brokenness went through.  I guess the 
git repo is not the source of truth for that. The integrations 
yesterday were failing seemingly unrelated to the patch. Folks seemed 
generally unsurprised this was happening and attributed it to 
flakiness that is generally known and that force pushes are the way to 
deal with that.

Is this customary? Force pushing because the CI results are too flaky 
to be trusted?

*From:*Simon Hausmann
*Sent:* Tuesday, December 12, 2017 3:09:03 AM
*To:* Adam Treat; development@qt-project.org
*Subject:* Re: [Development] COIN failures on dev

Hi,

I find the easiest way to find the last successful integration for 
example for qt5.git dev is this:

    (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

    (2) Click on the last commit in the branch

    (3) Click on the "Change-Id" link or paste the commit sha1 into 
the Gerrit search field

    (4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual 
integration and what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in 
this case).

The git repo is our source of truth, and from there it's easy to get 
back to gerrit and then the CI. All of the above steps can also be 
done entirely in a CLI way by using Gerrit's ssh query interface.

Simon

*From:*Development 
 on behalf of 
Adam Treat 

*Sent:* Monday, December 11, 2017 5:47:41 PM
*To:* development@qt-project.org
*Subject:* Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated 
reasons.

>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> 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] COIN failures on dev

2017-12-12 Thread Tuukka Turunen

Hi,

Force pushing of what? Of course in a situation where nothing else is possible, 
we need to have a way to unblock CI by forced push. But we are not pushing 
other than really mandatory fixes in bypassing the CI.

It is very unfortunate that dev has been broken for a while, but work is 
ongoing to unblock it.

Yours,

Tuukka

From: Development  on 
behalf of Adam Treat 
Date: Tuesday, 12 December 2017 at 13.10
To: Simon Hausmann , "development@qt-project.org" 

Subject: Re: [Development] COIN failures on dev

Ah, so last successful integration on qt5 super module was nearly a month ago?? 
11/172017

Now, what I was really after was last generally unsuccessful integration to see 
how all the brokenness went through.  I guess the git repo is not the source of 
truth for that. The integrations yesterday were failing seemingly unrelated to 
the patch. Folks seemed generally unsurprised this was happening and attributed 
it to flakiness that is generally known and that force pushes are the way to 
deal with that.

Is this customary? Force pushing because the CI results are too flaky to be 
trusted?

From: Simon Hausmann
Sent: Tuesday, December 12, 2017 3:09:03 AM
To: Adam Treat; development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Hi,

I find the easiest way to find the last successful integration for example for 
qt5.git dev is this:

(1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

(2) Click on the last commit in the branch

(3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit 
search field

(4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual integration and 
what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this 
case).

The git repo is our source of truth, and from there it's easy to get back to 
gerrit and then the CI. All of the above steps can also be done entirely in a 
CLI way by using Gerrit's ssh query interface.

Simon

From: Development  on 
behalf of Adam Treat 
Sent: Monday, December 11, 2017 5:47:41 PM
To: development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated reasons.
>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> 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] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Konstantin Tokarev



12.12.2017, 16:53, "Denis Shienkov" :
>  > Did you try QQuickItem::grabToImage?
>
> Of course, it is veeery slowly.

I guess your best bet then is hardware grabbing video output

>
> 12.12.2017 16:40, Konstantin Tokarev пишет:
>>  12.12.2017, 16:13, "Denis Shienkov" :
>>>  Hi all...
>>>
>>>  Is it possible to grab a QQuickItem content (e.g. with all sub-items)
>>>  when an item changes?
>>  Did you try QQuickItem::grabToImage?
>>
>>>  E.g. with widgets I use the following code:
>>>
>>>  bool MyWidget::event(QEvent *event)
>>>  {
>>>    if (event->type() == QEvent::UpdateRequest)
>>>    myGrab();
>>>    return QWidget::event(event);
>>>  }
>>>
>>>  void MyWidget::myGrab()
>>>  {
>>>    ...
>>>    QBackingStore *store = backingStore();
>>>    Q_ASSERT(store);
>>>
>>>    QPaintDevice *pdev = store->paintDevice();
>>>    const auto image = dynamic_cast(pdev);
>>>    ...
>>>  }
>>>
>>>  it is very fast (as I know)...
>>>
>>>  But with the QML I got a troubles: I can 'grab' the sourceItem, using
>>>  the FBO and private functions, but the fbo::toImage() is too slow (~24
>>>  msecs),
>>>  and I don't know how to intercept the signal when a watched item updates:
>>>
>>>  Grabber::Grabber(QQuickItem *parent)
>>>    : QQuickItem(parent)
>>>  {
>>>    setFlag(QQuickItem::ItemHasContents);
>>>  }
>>>
>>>  // Where sourceItem - is a watched item.
>>>  void Grabber::setSourceItem(QQuickItem *sourceItem)
>>>  {
>>>    if (sourceItem == m_sourceItem)
>>>    return;
>>>    m_sourceItem = sourceItem;
>>>    emit sourceItemChanged(m_sourceItem);
>>>    update();
>>>  }
>>>
>>>  QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
>>>  UpdatePaintNodeData 
>>> *updatePaintNodeData)
>>>  {
>>>    Q_UNUSED(updatePaintNodeData);
>>>
>>>    if (!m_sourceItem)
>>>    return oldNode;
>>>
>>>    QSGRootNode root;
>>>  root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());
>>>
>>>    const QScopedPointer renderer(
>>>    QQuickItemPrivate::get(this)->
>>>    sceneGraphRenderContext()->createRenderer());
>>>
>>>    renderer->setRootNode();
>>>
>>>    const QSize size(m_sourceItem->width(), m_sourceItem->height());
>>>    renderer->setDeviceRect(size);
>>>    renderer->setViewportRect(size);
>>>    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
>>>    renderer->setClearColor(Qt::transparent);
>>>
>>>    QOpenGLFramebufferObject fbo(size);
>>>    renderer->renderScene(BindableFbo());
>>>    fbo.release();
>>>
>>>    QElapsedTimer et;
>>>    et.start();
>>>    const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
>>>    qDebug() << "Elapsed:" << et.elapsed();
>>>
>>>    return oldNode;
>>>  }
>>>
>>>  it is very fast (as I know).
>>>
>>>  But with the QML I got a troubles: I can 'grub' an item, using the FBO,
>>>
>>>  but the toImage() method is too slow (~24 msecs), and I don't know how
>>>
>>>  to intercept a signal when the watched item updates:
>>>
>>>  Grabber::Grabber(QQuickItem *parent)
>>>    : QQuickItem(parent)
>>>  {
>>>    setFlag(QQuickItem::ItemHasContents);
>>>  }
>>>
>>>  QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
>>>  UpdatePaintNodeData 
>>> *updatePaintNodeData)
>>>  {
>>>    Q_UNUSED(updatePaintNodeData);
>>>
>>>    if (!m_sourceItem)
>>>    return oldNode;
>>>
>>>    QSGRootNode root;
>>>  root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());
>>>
>>>    const QScopedPointer renderer(
>>>    QQuickItemPrivate::get(this)->
>>>    sceneGraphRenderContext()->createRenderer());
>>>
>>>    renderer->setRootNode();
>>>
>>>    const QSize size(m_sourceItem->width(), m_sourceItem->height());
>>>    renderer->setDeviceRect(size);
>>>    renderer->setViewportRect(size);
>>>    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
>>>    renderer->setClearColor(Qt::transparent);
>>>
>>>    QOpenGLFramebufferObject fbo(size);
>>>    renderer->renderScene(BindableFbo());
>>>    fbo.release();
>>>
>>>    QElapsedTimer et;
>>>    et.start();
>>>    const QImage image = fbo.toImage(); // TOO LONG!
>>>    qDebug() << "Elapsed:" << et.elapsed();
>>>
>>>    return oldNode;
>>>  }
>>>
>>>  ___
>>>  Development mailing list
>>>  Development@qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Denis Shienkov


Now I tried to use the following code:

classBindableFbofinal:publicQSGBindable

{

public:

explicitBindableFbo(QOpenGLFramebufferObject*fbo)

:m_fbo(fbo)

{}

voidbind()constfinal{m_fbo->bind();}

private:

QOpenGLFramebufferObject*m_fbo=nullptr;

};

Grabber::Grabber(QQuickItem*parent)

:QQuickItem(parent)

{

setFlag(QQuickItem::ItemHasContents);

connect(this,::windowChanged,

this,::scheduleWindowChange);

}

voidGrabber::setSourceItem(QQuickItem*sourceItem)

{

if(sourceItem==m_sourceItem)

return;

m_sourceItem=sourceItem;

emitsourceItemChanged(m_sourceItem);

update();

}

QQuickItem*Grabber::sourceItem()const

{

returnm_sourceItem;

}

QSGNode*Grabber::updatePaintNode(QSGNode*oldNode,

UpdatePaintNodeData*updatePaintNodeData)

{

Q_UNUSED(updatePaintNodeData);

if(!m_sourceItem)

returnoldNode;

m_running=true;

constautoitemNode=QQuickItemPrivate::get(m_sourceItem)->itemNode();

constautoparentNode=itemNode->parent();

constautosiblingNode=itemNode->previousSibling();

if(parentNode)

parentNode->removeChildNode(itemNode);

constQScopedPointerrenderer(

QQuickItemPrivate::get(this)->

sceneGraphRenderContext()->createRenderer());

QSGRootNoderootNode;

rootNode.appendChildNode(itemNode);

renderer->setRootNode();

constQSizesize(m_sourceItem->width(),m_sourceItem->height());

renderer->setDeviceRect(size);

renderer->setViewportRect(size);

renderer->setProjectionMatrixToRect(QRectF(QPointF(),size));

renderer->setClearColor(Qt::transparent);

QOpenGLFramebufferObjectfbo(size);

renderer->renderScene(BindableFbo());

fbo.release();

rootNode.removeChildNode(itemNode);

if(parentNode){

if(siblingNode){

parentNode->insertChildNodeAfter(itemNode,siblingNode);

}else{

parentNode->prependChildNode(itemNode);

}

}

QElapsedTimeret;

et.start();

constQImageimage=fbo.toImage();//TOOLONG!

staticintcount=0;

qDebug()<<"Elapsed:"< wrote:


Did you try QQuickItem::grabToImage?

Of course, it is veeery slowly.

If the frame was rendered on the GPU, you have to download it from there, and 
that is slower than if you had rendered into CPU memory, as widgets do by 
default.  Thus the note in the docs:

   Note: This function will render the item to an offscreen surface and copy
   that surface from the GPU's memory into the CPU's memory, which can be
   quite costly. For "live" preview, use layers or ShaderEffectSource.

So, maybe try to get the GPU to do whatever comes next after you think you need 
to grab the frame?  grabToImage is more for archival, not for real-time effects 
(although I did use it recently to record an animated GIF; I could only get 
30FPS despite using a fairly powerful GPU, but that was good enough).

___
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] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Shawn Rutledge

> On 12 Dec 2017, at 14:53, Denis Shienkov  wrote:
> 
> > Did you try QQuickItem::grabToImage?
> 
> Of course, it is veeery slowly.

If the frame was rendered on the GPU, you have to download it from there, and 
that is slower than if you had rendered into CPU memory, as widgets do by 
default.  Thus the note in the docs:

  Note: This function will render the item to an offscreen surface and copy 
  that surface from the GPU's memory into the CPU's memory, which can be 
  quite costly. For "live" preview, use layers or ShaderEffectSource.

So, maybe try to get the GPU to do whatever comes next after you think you need 
to grab the frame?  grabToImage is more for archival, not for real-time effects 
(although I did use it recently to record an animated GIF; I could only get 
30FPS despite using a fairly powerful GPU, but that was good enough).

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Denis Shienkov


> Did you try QQuickItem::grabToImage?

Of course, it is veeery slowly.


12.12.2017 16:40, Konstantin Tokarev пишет:


12.12.2017, 16:13, "Denis Shienkov" :

Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

Did you try QQuickItem::grabToImage?


E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
  if (event->type() == QEvent::UpdateRequest)
  myGrab();
  return QWidget::event(event);
}

void MyWidget::myGrab()
{
  ...
  QBackingStore *store = backingStore();
  Q_ASSERT(store);

  QPaintDevice *pdev = store->paintDevice();
  const auto image = dynamic_cast(pdev);
  ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24
msecs),
and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
  : QQuickItem(parent)
{
  setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
  if (sourceItem == m_sourceItem)
  return;
  m_sourceItem = sourceItem;
  emit sourceItemChanged(m_sourceItem);
  update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
    UpdatePaintNodeData *updatePaintNodeData)
{
  Q_UNUSED(updatePaintNodeData);

  if (!m_sourceItem)
  return oldNode;

  QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

  const QScopedPointer renderer(
  QQuickItemPrivate::get(this)->
  sceneGraphRenderContext()->createRenderer());

  renderer->setRootNode();

  const QSize size(m_sourceItem->width(), m_sourceItem->height());
  renderer->setDeviceRect(size);
  renderer->setViewportRect(size);
  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
  renderer->setClearColor(Qt::transparent);

  QOpenGLFramebufferObject fbo(size);
  renderer->renderScene(BindableFbo());
  fbo.release();

  QElapsedTimer et;
  et.start();
  const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
  qDebug() << "Elapsed:" << et.elapsed();

  return oldNode;
}

it is very fast (as I know).

But with the QML I got a troubles: I can 'grub' an item, using the FBO,

but the toImage() method is too slow (~24 msecs), and I don't know how

to intercept a signal when the watched item updates:

Grabber::Grabber(QQuickItem *parent)
  : QQuickItem(parent)
{
  setFlag(QQuickItem::ItemHasContents);
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
    UpdatePaintNodeData *updatePaintNodeData)
{
  Q_UNUSED(updatePaintNodeData);

  if (!m_sourceItem)
  return oldNode;

  QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

  const QScopedPointer renderer(
  QQuickItemPrivate::get(this)->
  sceneGraphRenderContext()->createRenderer());

  renderer->setRootNode();

  const QSize size(m_sourceItem->width(), m_sourceItem->height());
  renderer->setDeviceRect(size);
  renderer->setViewportRect(size);
  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
  renderer->setClearColor(Qt::transparent);

  QOpenGLFramebufferObject fbo(size);
  renderer->renderScene(BindableFbo());
  fbo.release();

  QElapsedTimer et;
  et.start();
  const QImage image = fbo.toImage(); // TOO LONG!
  qDebug() << "Elapsed:" << et.elapsed();

  return oldNode;
}

___
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] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Konstantin Tokarev



12.12.2017, 16:13, "Denis Shienkov" :
> Hi all...
>
> Is it possible to grab a QQuickItem content (e.g. with all sub-items)
> when an item changes?

Did you try QQuickItem::grabToImage?

>
> E.g. with widgets I use the following code:
>
> bool MyWidget::event(QEvent *event)
> {
>  if (event->type() == QEvent::UpdateRequest)
>  myGrab();
>  return QWidget::event(event);
> }
>
> void MyWidget::myGrab()
> {
>  ...
>  QBackingStore *store = backingStore();
>  Q_ASSERT(store);
>
>  QPaintDevice *pdev = store->paintDevice();
>  const auto image = dynamic_cast(pdev);
>  ...
> }
>
> it is very fast (as I know)...
>
> But with the QML I got a troubles: I can 'grab' the sourceItem, using
> the FBO and private functions, but the fbo::toImage() is too slow (~24
> msecs),
> and I don't know how to intercept the signal when a watched item updates:
>
> Grabber::Grabber(QQuickItem *parent)
>  : QQuickItem(parent)
> {
>  setFlag(QQuickItem::ItemHasContents);
> }
>
> // Where sourceItem - is a watched item.
> void Grabber::setSourceItem(QQuickItem *sourceItem)
> {
>  if (sourceItem == m_sourceItem)
>  return;
>  m_sourceItem = sourceItem;
>  emit sourceItemChanged(m_sourceItem);
>  update();
> }
>
> QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
>    UpdatePaintNodeData *updatePaintNodeData)
> {
>  Q_UNUSED(updatePaintNodeData);
>
>  if (!m_sourceItem)
>  return oldNode;
>
>  QSGRootNode root;
> root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());
>
>  const QScopedPointer renderer(
>  QQuickItemPrivate::get(this)->
>  sceneGraphRenderContext()->createRenderer());
>
>  renderer->setRootNode();
>
>  const QSize size(m_sourceItem->width(), m_sourceItem->height());
>  renderer->setDeviceRect(size);
>  renderer->setViewportRect(size);
>  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
>  renderer->setClearColor(Qt::transparent);
>
>  QOpenGLFramebufferObject fbo(size);
>  renderer->renderScene(BindableFbo());
>  fbo.release();
>
>  QElapsedTimer et;
>  et.start();
>  const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
>  qDebug() << "Elapsed:" << et.elapsed();
>
>  return oldNode;
> }
>
> it is very fast (as I know).
>
> But with the QML I got a troubles: I can 'grub' an item, using the FBO,
>
> but the toImage() method is too slow (~24 msecs), and I don't know how
>
> to intercept a signal when the watched item updates:
>
> Grabber::Grabber(QQuickItem *parent)
>  : QQuickItem(parent)
> {
>  setFlag(QQuickItem::ItemHasContents);
> }
>
> QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
>    UpdatePaintNodeData *updatePaintNodeData)
> {
>  Q_UNUSED(updatePaintNodeData);
>
>  if (!m_sourceItem)
>  return oldNode;
>
>  QSGRootNode root;
> root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());
>
>  const QScopedPointer renderer(
>  QQuickItemPrivate::get(this)->
>  sceneGraphRenderContext()->createRenderer());
>
>  renderer->setRootNode();
>
>  const QSize size(m_sourceItem->width(), m_sourceItem->height());
>  renderer->setDeviceRect(size);
>  renderer->setViewportRect(size);
>  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
>  renderer->setClearColor(Qt::transparent);
>
>  QOpenGLFramebufferObject fbo(size);
>  renderer->renderScene(BindableFbo());
>  fbo.release();
>
>  QElapsedTimer et;
>  et.start();
>  const QImage image = fbo.toImage(); // TOO LONG!
>  qDebug() << "Elapsed:" << et.elapsed();
>
>  return oldNode;
> }
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Denis Shienkov



12.12.2017 16:13, Denis Shienkov пишет:

Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
    if (event->type() == QEvent::UpdateRequest)
    myGrab();
    return QWidget::event(event);
}

void MyWidget::myGrab()
{
    ...
    QBackingStore *store = backingStore();
    Q_ASSERT(store);

    QPaintDevice *pdev = store->paintDevice();
    const auto image = dynamic_cast(pdev);
    ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24 
msecs),

and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
    if (sourceItem == m_sourceItem)
    return;
    m_sourceItem = sourceItem;
    emit sourceItemChanged(m_sourceItem);
    update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData 
*updatePaintNodeData)

{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] How fast grab a QML item's content to image when it updates?

2017-12-12 Thread Denis Shienkov


Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
    if (event->type() == QEvent::UpdateRequest)
    myGrab();
    return QWidget::event(event);
}

void MyWidget::myGrab()
{
    ...
    QBackingStore *store = backingStore();
    Q_ASSERT(store);

    QPaintDevice *pdev = store->paintDevice();
    const auto image = dynamic_cast(pdev);
    ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24 
msecs),

and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
    if (sourceItem == m_sourceItem)
    return;
    m_sourceItem = sourceItem;
    emit sourceItemChanged(m_sourceItem);
    update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData *updatePaintNodeData)
{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}

it is very fast (as I know).

But with the QML I got a troubles: I can 'grub' an item, using the FBO,

but the toImage() method is too slow (~24 msecs), and I don't know how

to intercept a signal when the watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData *updatePaintNodeData)
{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] COIN failures on dev

2017-12-12 Thread Adam Treat

Ah, so last successful integration on qt5 super module was nearly a month ago?? 
11/172017

Now, what I was really after was last generally unsuccessful integration to see 
how all the brokenness went through.  I guess the git repo is not the source of 
truth for that. The integrations yesterday were failing seemingly unrelated to 
the patch. Folks seemed generally unsurprised this was happening and attributed 
it to flakiness that is generally known and that force pushes are the way to 
deal with that.

Is this customary? Force pushing because the CI results are too flaky to be 
trusted?

From: Simon Hausmann
Sent: Tuesday, December 12, 2017 3:09:03 AM
To: Adam Treat; development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Hi,

I find the easiest way to find the last successful integration for example for 
qt5.git dev is this:

(1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

(2) Click on the last commit in the branch

(3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit 
search field

(4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual integration and 
what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this 
case).

The git repo is our source of truth, and from there it's easy to get back to 
gerrit and then the CI. All of the above steps can also be done entirely in a 
CLI way by using Gerrit's ssh query interface.

Simon

From: Development  on 
behalf of Adam Treat 
Sent: Monday, December 11, 2017 5:47:41 PM
To: development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated reasons.
>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> 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] COIN failures on dev

2017-12-12 Thread Simon Hausmann

Hi,

I find the easiest way to find the last successful integration for example for 
qt5.git dev is this:

(1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch

(2) Click on the last commit in the branch

(3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit 
search field

(4) At the bottom of the change in Gerrit you can find a link to 
https://testresults.qt.io/ with more details about the actual integration and 
what other changes it was tested together with 
(https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this 
case).

The git repo is our source of truth, and from there it's easy to get back to 
gerrit and then the CI. All of the above steps can also be done entirely in a 
CLI way by using Gerrit's ssh query interface.

Simon

From: Development  on 
behalf of Adam Treat 
Sent: Monday, December 11, 2017 5:47:41 PM
To: development@qt-project.org
Subject: Re: [Development] COIN failures on dev

Whenever I discover something seemingly broken in an area of code I'm
unfamiliar with I first suspect I don't understand something...

Right now I'm looking for the last successful dev branch integration on
qt5 supermodule and I can not find it. I've gone back to before
Thanksgiving.

Can this possibly be correct??

Where is the dashboard showing the last successful integration for a
given branch?

On 12/11/2017 11:24 AM, Adam Treat wrote:
> Hi,
>
> For the past few business days we've all witnessed failures on dev
> branch like this: https://codereview.qt-project.org/#/c/213309/
>
> Seems that something broke with provisioning on macOS or something. I
> see this https://codereview.qt-project.org/#/c/214045/ attempt to fix,
> but that is also failing to integrate due to seemingly unrelated reasons.
>
> I'm disturbed that I haven't seen any widely shared communication
> about this, how it broke, what is being done to fix, or what can be
> done to stop it in the future.
>
> Things seem really broken with our CI system in general. I wonder that
> this isn't the normalization of deviance. Has the project just given
> up and regards this as standard operating procedure?
>
> - Adam
>
> ___
> 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] QtBase broken in 5.9 and 5.10. Fix is already inbound.

Re: [Development] Module "" () : on QtRemoteObjects

[Development] Module "" () : on QtRemoteObjects

Re: [Development] COIN failures on dev

Re: [Development] COIN failures on dev

Re: [Development] How fast grab a QML item's content to image when it updates?

Re: [Development] How fast grab a QML item's content to image when it updates?

Re: [Development] How fast grab a QML item's content to image when it updates?

Re: [Development] How fast grab a QML item's content to image when it updates?

Re: [Development] How fast grab a QML item's content to image when it updates?

Re: [Development] How fast grab a QML item's content to image when it updates?

[Development] How fast grab a QML item's content to image when it updates?

Re: [Development] COIN failures on dev

Re: [Development] COIN failures on dev

14 matches

Site Navigation

Mail list logo

Footer information