Text component sometimes causes a malfunction

[paiext]

The following codes cause the app to become unresponsive:
If you change myText.text to "Foo" or remove the horizontalCenter anchor option, the app will run normally.

In addition, this symptom does not occur on my desktop, but only on my laptop.

Rectangle {
  width: 60;
  height: 30;
  radius: 5; 
  border.width: 1;
  border.color: 'red';
  Text {
    anchors.horizontalCenter: parent.horizontalCenter;      
    color: 'white';
    font.pixelSize: 12;
    font.family: "Tahoma";        
    text: 'Get In';
  }    
} 

[whoozle]

is it with the latest qmlcore? :|

[paiext]

@whoozle > is it with the latest qmlcore? :|

of course, i checked it out several times 😃

[whoozle]

Even though I could not reproduce it I reverted 48fff9c as it should be fixed differently (returns -1 padding on height: paintedHeight

Could you please try it again

[whoozle]

ignore comment above, I've modified example to make it happen every time :)

[whoozle]

Rectangle {
  width: parent.width;
  height: 30;
  radius: 5; 
  border.width: 1;
  border.color: 'red';
  color: 'gray';
  Text {
    anchors.horizontalCenter: parent.horizontalCenter;      
    color: 'white';
    font.pixelSize: parent.width / 10;
    font.family: "Tahoma";        
    text: 'Get In';
    onWidthChanged: { log(value); }
  }    
} 

just open inspector window and drag right side of HTML view to the right, eventually it will stuck in loop. I'm pretty sure it's rounding error, but I have to think how to tolerate it.

[whoozle]

I figured out what happened and it's really weird.

Returned sizes have 1px difference. You're attaching text's center using anchor, this means we have to know text size to properly calculate position (left: -width/2)

Text size dependencies are bi-directional. On one hand we have default width: paintedWidth rule, on other hand if you're setting width yourself, you may enforce limit on text size.

So what happens:

1. Someone calls layoutText, and it returns some value, let's say 71
2. Text handles the fact that width has changed, and trigger layout again (unfortunately this overhead is hardly fixable).
3. The same input, the same sizes, the same styles, etc, result in size 70. We trigger layout again, as you may want to recalculate text bounds and it returns 71, 70, 71, 70.

It looks like skipping -1 update fixes the problem. The reason I keep +1 update, is that there's rounding error in fullWidth, which is rounding result. It may or may not contain the last subpixel

I see similar effect in this textarea in github. Adding the same letter over and over again, gives +1/-1 and makes the lower bound of textarea jump up and down

Proper fix will be is to skip certain relayouts, but the open question is how to define scenarious to skip