0

I have a visual tree of the following object:

Row {
  spacing: 4
  y: 1
  U_Icon {
    width: 48
    height: 48
    scale: (activeo === main.object ? 1.18 : 1) * (main.expand ? 1 : 0.75)
    Behavior on scale { SpringAnimation { spring: 10; damping: 0.2; duration: 100 } }
    color: activeo == object ? "white" : "#262626"
    anchors.verticalCenter: parent.verticalCenter
  }
  Column {
    spacing: -10
    Text {
      text: object.type + "type"
      font.pointSize: 10
      font.family: sysfont
    }
    Text {
      text: "name"
      font.pointSize: 20
      font.family: sysfont
      font.italic: true
      font.letterSpacing: -1
    }
  }
}

The scale of the icon depends on whether the current object is selected or expanded. Expanding causes the object to draw its children objects. However, on re-expanding after contracting, depending on the tree structure, children objects are missing their text, which mysteriously reappears when another object is selected or created. Selecting another object might cause one, several or all missing texts to appear, the same goes for creating another object. When the tree is expanded, the texts are there for an instant, after which they disappear.

I made a few observations:

  • if the binding for the scale is only either of the two expressions without the other, the problem does not manifest
  • if the animation is removed, the problem does not manifest
  • interfacing the icon scale as an alias property of the row in order to move the binding out of the component and to the place it is instantiated has no effect, the problem persist
  • breaking down the binding expression by adding dedicated activefactor and expandfactor property for each expression and reducing the scale binding to activefactor * expandfactor has no effect, the problem persists
  • refactoring the binding expression to a code block with a return statement (sometimes that helps when single liners fail) has no effect, the problem persists

Here is an illustration of what's going on: enter image description here

1 - the tree builds OK
2 - the tree is collapsed
3 - the tree is expanded again, the text flashes for a moment and disappears
4 - clicking arbitrary object causes all text to reappear

Any ideas what's going on? Yet another bug or am I missing something? Why would a slightly more complex expression cause the column with the text to disappear? It is not a problem of the changing scale in particular, since both expressions change it and both work on their own.

Note that the text is still there, just not being rendered by the scene-graph, that is evident from the size of the light-grey rounded rectangle which is sized to match the row width. The scale of the icon itself is evaluated and displayed property, but for some reason causes the text to disappear.

EDIT: Another curious observation, if the text column is replaced by a common rectangle, the bug does not manifest. If the column is wrapped inside a rectangle the same width as the column, but only as high as the small text, this causes only the large text to go missing:

enter image description here

This adds more weight to my suspicion that this is a bug in the scene-graph, and wrapping it in a rectangle forces the renderer to update only that portion of the missing text. Note that the rectangle is not clipping the column. Furthermore, if the rectangle color is set to #00000000, that is fully transparent, the text is missing again, the scene graph disregards it, and thus there is nothing to force the update of the text part. As expected, wrapping in an Item is no help either, nor is using text directly, without the column. If the rectangle is extended further down, it cuts through the big text, as a result, only the upper half of the big text is visible. Even the tiniest amount of transparency in the rectangle causes the text to go missing, even if the rectangle is 99.99% opaque. Only a 100% opaque rectangle forces the visibility of the text.

I have tested it with latest Qt 5.7 on windows 7 x64 (stock x86 qt build + custom x64 opengl static) and linux x64 (using the mesa drivers).

dtech
  • 47,916
  • 17
  • 112
  • 190
  • The prize for the first reproducible QML example is still not taken. – Velkan Sep 11 '16 at 16:43
  • @Velkan - I have shared the relevant code, that's what breaks it, the rest is thousands of lines of proprietary code what works flawlessly. In the cases where it is possible to reproduce the issue in an isolated snippet I have done so, for example: http://stackoverflow.com/questions/33792876/qml-garbage-collection-deletes-objects-still-in-use – dtech Sep 11 '16 at 16:50
  • That was just a long version of "can't reproduce". – Velkan Sep 11 '16 at 16:59
  • @Velkan - I am sure you are eager yo see how the big boys are coding, unfortunately for you, this code is not public for the time being. I've already found workaround, I am just posting on the odd chance someone knows something on the subject, not you obviously ;) – dtech Sep 11 '16 at 17:06
  • Haven't noticed that it is you again. – Velkan Sep 11 '16 at 17:10
  • @Velkan - the context of your first comment suggests your previous comment is a lie. Or maybe you are simply in the habit of whining about each and every problem that is not trivial to reproduce? – dtech Sep 11 '16 at 17:34

0 Answers0