Updating LabelItem text on sigXRangeChanged leaves artefacts of old text when using auto-range button

[tblum]

Short description

This bug is strange and only comes up in very specific circumstances. I have made a short example to reproduce it. So I register a callback function on sigXRangeChanged which updates the text in a LabelItem. The problem arises when the updated text is shorter than the previous text - but only in some cases: i.e. when resetting the plot's range via the auto-range button.

To reproduce

1. Run the example
2. Zoom in and out on the X-axis: You will see the text below the Plot change as expected.
3. Zoom out so a long string is displayed (i.e. the whole alaphabet.
4. Now click the auto-range button [A]: You will see the new string 'ABCDEF' printed on top of the old (longer string). Even when zooming the old text will remain until you have zoomed so far out as to overwrite the whole space occupied by the old long string.

Code to reproduce

import numpy as np
import pyqtgraph as pg
from functools import partial

def update_label(lab, vb, r):
    l = int(r[1] - r[0])
    lab.setText(''.join([chr(65+ x % 26) for x in range(l)]))

w = pg.GraphicsLayoutWidget()
lab = pg.LabelItem('Label')
w.nextRow()
x = np.linspace(0, 6, 1000)
y = np.sin(x)
p = w.addPlot(x=x,y=y)
p.sigXRangeChanged.connect(partial(update_label, lab))
w.nextRow()
w.addItem(lab)
w.show()

if __name__ == '__main__':
    pg.exec()

Expected behavior

The new updated string should be displayed in the LabelItem below the plot

Real behavior

When the updated text is shorter than the previous text, one can see parts of the old / previous text. And it stays around until a longer text is displayed.

Tested environment(s)

• PyQtGraph version: 0.14.0dev0 and 0.13.7
• Qt Python binding:
• Python version: 12.7
• NumPy version: 2.1.2
• Operating system: Windows
• Installation method: pip

Additional context

[pijyoi]

I found that your issue goes away if you use a QtCore.Qt.ConnectionType.QueuedConnection.

[tblum]

@pijyoi That works thanks :) Would you consider that a fix, or more of a workaround? I.e. should I have know that a QueuedConnection is required for this?

Best regards Troels Blum

[pijyoi]

I would consider it more of a workaround. For QueuedConnection to have "fixed" this, it means that there is an order of callbacks issue.

Using QueuedConnection has the effect of having the callback being called "later".