@Pl45m4 Yes im using a plain windows 10 system. And yes the linked bug is with MSys2 as i searched for a similar problem and this was the only thing related i could find. Found it odd myself that i worked inside qt creator but crashed outside (as said i tried windeploy and run dependency walker but haven't found a problem there) As said using llvm solves it for me but still wanted to point it out for others may experiencing something simlar. @Christian-Ehrlicher i posted all code above simply create a new project and add in my code for maindwindow.h and .cpp. There is nothing else in my project.

@herocon Ok next attempt: ui->label->setPixmap(p.scaled(ui->label->size())); Each iteration scales the pixmap to current label size and then sets the pixmap to the label. By doing this, the size of the label increases with the pixmap (because of border/frame... IIRC 1px per side by default, so 2px in total). Then you take the new label size again in the next iteration and apply this new (by 2px) increased size to the pixmap... the label gets the pixmap, grows by about 2px in height and there you have your loop where your label and consequently the whole widget grows ;-) So still no bug :) And it's exactly the behavior you would expect from the debug output. (The height increases by 2 each timer interval). When using another layout setup, the layout/other widgets might "buffer" that, so the main app window does not grow. But even there, the label itself should definitely grow when you periodically set content which has the exact same size as the outter boundings of the label. Why though?! Try (not tested): int w = ui->label->width(); int h = ui->label->height(); ui->label->setPixmap(p.scaled(w - 2, h - 2)); // or this and set the pixmap only once ui->label->setScaledContents(true); Because a label with w=500, h=500 for example, can't display a pixmap with w=500, h=500. If you set a pixmap with the same size as the label itself, it will start to grow.

That was a nasty one. Glad you found out and thanks for sharing !

@JonB said: Which I have always regraded as devil's spawn Agreed. I see blockSignals() as an advanced tool to be used with great care and only when you're very aware of all consequences in given case. Similar to sender(). Definitely not something to be applied on a "let's see if it helps" basis.

@stvsl said in Text Rendering Issue in Qt for MCU Applications: If you require additional details or examples to assist in the resolution process, please do not hesitate to reach out. You need to provide your exact system configuration, build steps, and other relevant details in order for anyone to look at your issue effectively.

@hskoglund Thank you, that solution solved my issue. A note for anybody else: I was running 6.6.0-rc and thought that it would have the patch. Once I downloaded 6.5.2 and used that kit it worked.

@SGaist, yes Qt 6.5

So if anyone finds the same issue, the workaround can be found here: https://github.com/probonopd/linuxdeployqt/issues/554 I just put the line: qputenv("QTWEBENGINE_CHROMIUM_FLAGS", "--disable-gpu --no-sandbox"); And everything started to work.

I realized that the erroneous behaviour is caused by the Page Object. The same happens if Page is replaced with Pane. However it works if one uses Control or Item instead. I hope this helps if someone encounters the same issue. Maybe it will be fixed in future Qt versions.

@SGaist Thanks problem solved! (PySide6 updated to 6.3.1)

I am using version 6.5.2. and I also have this bug.

@Wenchi said in Crash in function: QImageData * QImageData::create(const QSize &size, QImage::Format format): Although the code is crashing in various places, but the crash point is always the same: But that is likely --- or just as possible --- indicating you have a problem elsewhere which only shows up here, such as corrupted/misallocated memory? How else would you explain it "crashing" in e.g. QList<MyWidget>.push_back()? by the way, I'm fired. ready to get a new start I am sorry to hear that, good luck for future.

Hi, A minimal compilable example would be nice for the bug report. Did you also check with Qt 5.15.0 and 5.15.1 ? Just in case it something that changed with 5.15.2.

It turned out to be the same bug as described here: https://forum.qt.io/topic/124259/item-could-not-be-created/28 I followed the solution proposed there and with some tweaking of the Environment Kit I got it to work. Worked for me using Qt Desktop 5.15.1 MinGW 64-bit. Did NOT work with Qt Desktop 5.15.1 MSVS201x 64-bit. Have not tried version 6 (because of python conflicts with Pyside 2).

@Vasiliy-Isaikin said in QFrame border has differend line width but frameShadow is plain: Why? It looks like you're not using layouts? You should arrange your widgets in layouts, so they get sized and positioned properly.

@afalco said in Possible bug in QSplitter: sizes set can't be read back: But the sizes I get back from QSplitter::sizes() are not the one I set, unless I visit the tab. Qt sizes are only reported correctly once a widget is shown.

@jsulm That is correct, but I'd first try with the latest Qt 5 version 5.15.2 Regards

I found out that I can reproduce this behavior by setting QT_DISTANCEFIELD_DEFAULT_BASEFONTSIZE, QT_DISTANCEFIELD_DEFAULT_SCALE and QT_DISTANCEFIELD_DEFAULT_RADIUS variables. With these, the problem occurs even on Windows. Not sure whether it's the same problem or not, but if QT_DISTANCEFIELD_DEFAULT_RADIUS is NOT DIVISIBLE by QT_DISTANCEFIELD_DEFAULT_SCALE, the problem occurs 100% of time (some letters will disappear). Example: export QT_DISTANCEFIELD_DEFAULT_BASEFONTSIZE=128 export QT_DISTANCEFIELD_DEFAULT_SCALE=12 export QT_DISTANCEFIELD_DEFAULT_RADIUS=96 // If I set this to 95 or 97 or anything not divisible by 12, it will break. Can someone explain me what these distancefield environment variables do and whether this is an intended behavior?