@leonardo-M-B Pass topLeft.column(), bottomRight.column() on to headerDataChanged()?

Where are you using that painter ?

Hi, Can you provide a minimal compilable code that shows that behaviour ?

@Angelking 恰好我也在做这方面的研究。 我的需求是，为我们的动作编辑器增添Direct3D的支持，因为用户更加习惯MME----这是一个基于HLSL的渲染框架。 这里问题在于我们使用的是Qt Quick，而现有的代码是和OpenGL深度绑定的，我们需要做的是考察哪些地方和OpenGL深度绑定的，然后尝试抽象出来，做好做成一个插件，我是考察Qt插件的写法决定将OpenGL相关的内容放在插件里实现。 想让Qt Quick应用和OpenGL和Direct3D解耦，我想一个方法就是使用RTT技术。就是采用不同的渲染器在一个纹理图上渲染，这样有可能通用。但是其中的难点感觉还是挺多的，现在在艰难地攻克。

@VRonin Yes, they are, but the pixmap is just grabbed QGraphicsView's content using grab() method.

How are you loading these lines ?

@SysTech Thanks again! You're very welcome. Those 3D displays are kind of handy for visualizing the radio output but they are right now pretty CPU intensive. If I may insert yet another suggestion here. While I don't believe you'd gain much by using OpenGL painting for the "waterfall" data, I think switching to it for the 3D displays would work better. I nice side effect would be that you can also render OpenGL from different threads, provided the appropriate locking mechanisms are in place. You could, as the most simple test, try using QOpenGLWidget for those FFT displays. Kind regards.

@kshegunov said: EDIT: Right I saw that you wrote a post. Yes, probably QTextDocument will be the more flexible way. Do consider the code sample I give you here though. Kind regards. Thank you very much for this, I will definitely try it!

Well yes, but you're painting that color with alpha over whatever widget is under the button, since the event filter is called before paint event of the button and you return true from it so the button's paint event is never actually called. To see the button painted underneath you need to actually call the paint event of the button manually before you overpaint it with your color. Unrelated comments: You seem to have a very bad habit of just casting types with a C cast to whatever you think you need at the moment. I'm referring to the QWidget *widget = (QWidget *)object; cast in the eventFilter. If I used any non-widget QObject derived type with your class it would compile successfully and crash at runtime. There's a isWidgetType() method on a QObject that you can test with before casting. Also please don't use C style casts. It's just plain evil and you will cause bugs with it. Either to yourself or other people that use your classes. There's a lot safer qobject_cast for QObject derived types that will return nullptr that you can test for if the type can't be cast. Painting in response to a timer with interval of 10ms makes no sense on almost any of user's machines. The typical display is ticking at 60Hz (i.e. little over 16ms) so anything lower than that is just giving Qt more work in filtering out the update requests you are flooding it with. Displays with a higher refresh rate are still very rare and even on them there's not gonna be a noticeable difference if you stick to 60Hz animation. Using == operator on a floating point numbers is on borderline of being a bug. You should practically never do that unless you're actually testing floating number stability, which is like super rare. Use non-strict comparisons (< and >) or just stick to fixed point integers for steps like that.

Hi, Do you mean move them at the right position ?

I found that this application also has the same issue (same error message when doing the same thing): https://local.ugene.unipro.ru/tracker/browse/UGENE-5411

Hi and welcome Do you mean if you can get/use the same "dialog" or more like the concept of how to make something pop up like that?

@Chris-Kawa said: t by value creates copies and is extremely bad for locality. Passing pointers is optimizer unfriendly. Always prefer a const referenc thanks for the advices! i will start working on it.