Dug around other similar topics and found a solution, posting it here in case anyone has a similar problem to mine. The solution is in this thread

It seems this is a 'problem' with high DPI displays in particular. I changed the way the program gets the X and Y coordinates from the mouse by taking into account the devicePixelRatio() as outlined in the linked thread, which solved the offsetting.

@slymas glad you found out and thanks for sharing ! :-)

@wookie

Oh man, getting Qt to work properly in a graphics intensive application at a good frame rate is tricky!

QOpenGLWidget has absolute dog shit performance. Unfortunately you need it if you want the best integration with the rest of the Qt and nice things such as context menus. In my tests though rendering with QOpenGLWidget has an order of magnitude worse performance than simply using a QGLWidget or just QWindow. I think something really stupid is happening inside the implementations.. (texture copy or something like that perhaps..)

In general one problem is that if your setSwapInterval actually works (plenty of bugs there across the whole stack) you're blocking your thread until your swap returns. So if your display is running at 60fps then you're stuck there for 16ms at a time which delays any user input processing that much since the event loop can't run. But it gets even worse if you're rendering multiple windows/widgets! If you're swapping twice then you're blocking twice and now your frame rate is halved, so you're dropping to 30fps and the UI is sluggish as a snail!

In my game editor I've got a decent enough solution but it has taken some effort.

Essentially what I've done is:

I've settled on QWindow myself and creating the context myself and then wrapping that up inside QWidgetContainer. I use a "busy loop" that runs and uses QApplication::processEvents directly with AllEvents | WaitMoreEvents I use a separate thread to give a heartbeat, it sleeps some user defined interval and then posts a message to the main thread (on windows it'll try to use the compositor flush to sleep). Main thread then renders on the heartbeat message. I disabled app level VSYNC completely (i.e setSwapInterval is always 0)

The key takeaways are that

if you use any kind of blocking such as VSYNC or thread sleep etc. in your main thread your UI janks! if you don't use any kind of blocking and just busy loop as fast you can in your event loop you burn a lot of cycles and drain the users battery!

so whatever solution you want to create you need

ideally scaling so the frame rate is good and scales to the load interruptible waits for throttling the main loop, react to user input as soon as possible steady fps with good timing resolution

@Hyperspider-Software

Resizing and moving the window will cause updates, renders and repaints. If everything is done and nothing changes, it doesn't have to get updated at such high rate as it would, when you grab the window and move it around and change dimensions of the content.
Just a guess. Maybe it might be helpful if you show some code, how the window is rendered.
Is it just one window or does everything behave like this?

@DWJO said in Ui doesn't launch when using openGL widgets.:

sometimes when debugging, the Ui doesn't launch

Please clarify this. only when debugging?
I might expect such behaviour in an otherwise correct program being debugged since openGL is its own command processing pipeline. think of it as "parallel processing". So, breakpoints in your Qt program might not consistently apply to what's going on in the GPU pipeline.

@kkoehne said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?:

@Yuni said in Qt6, qmake: Does 'QT += openglwidgets' imply 'QT += opengl'?:

If it works and it's unspecified behavior, then it may not work on other machines or for future Qt versions.

Build and module dependencies usually don't change in a minor Qt version. For major Qt versions, things might get rearranged ... but then again there's no SC guarantee there in the first place :)

I think it's good practice to explicitly declare all the dependencies that you explicitly rely upon though. But this is arguably a matter of taste.

I would guess qopenglwidget.prf fetches qopengl.prf - you can take a look into them by your own.

For QT variable, it's actually .prifiles: mkspecs/modules/qt_lib_qopenglwidgets.pri, mkspecs/modules/qt_lib_qopengl.pri ...

I see, thank you so much! I'll declare them explicitly then.

I've found the .pri files (without the leading 'q', that is, so e.g. qt_lib_opengl.pri) and openglwidgets indeed has a dependency on opengl, explaining why the project compiles without the explicit declaration.

It's been solved by create a process and launch the QOpenGLWidget's .exe file.

@harlamer Without a minimal compilable example that demonstrates the problem there's not much we can do. We do not know what platform, what font, what texture and texture setup, how the painter has been set up, what "displayed correctly" means, etc.