Navigation cube seems to get wrong mouse coordinates when built with qt6 about freecad

[maxwxyz]

Left or right click? Are you using a mouse, touch pad, touchscreeen?
Can you also try it in the weekly builds: https://github.com/FreeCAD/FreeCAD-Bundle/releases/tag/weekly-builds

[greyltc]

Mouse. Neither left nor right clicking works. I'll see if I can get a weekly build going and report back shortly.

[greyltc]

@maxwxyz Okay, I've built and tested whatever commit that latest weekly build you linked there is based on (a4dd600). The cube's behavior has changed in that now the cube and associated controls highlight whenever my pointer hovers over them, but still nothing up there responds in any way to any left or right mouse clicks/click+drag or anything at all. See attached video:
Screencast from 2024-04-16 11-33-00.webm I can't quite figure out why/when the cursor decides to change between a hand and an arrow. Right clicking brings up the menu as shown.

OS: Arch Linux (GNOME/gnome)
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.36874 (Git)
Build type: Release
Branch: makepkg
Hash: a4dd600ec6d5a53a9960cd9f8693d7d307b9e359
Python 3.11.8, Qt 6.7.0, Coin 4.0.2, Vtk 9.3.0, OCC 7.7.2
Locale: English/United States (en_US)

[maxwxyz]

I cannot reproduce on my system and never heard about this behavior. Could you try temporarily rename your user.cfg file?

[greyltc]

mv ~/.config/FreeCAD/ ~/.config/FreeCAD.bak then relaunch freecad did not impact the issue.

I've got this issue on multiple machines (desktops and laptops). Granted, these are all pretty similar setups: Arch Linux, gnome desktop environment, intel graphics, freecad from official Arch repos (and now the one test I did where I built from a4dd600)

[greyltc]

Wait a sec. This is probably just a duplicate of #13303

[maxwxyz]

@greyltc related to this one? https://gitlab.archlinux.org/archlinux/packaging/packages/freecad/-/issues/3

[xtemp09]

@greyltc, yes, it's a duplicate.

[adrianinsaval]

I consider this issue to be better at describing the navicube issue than the above and would advise to have this one open and close the other one instead.

@Rexbas would you have any clue why the navicube doesn't properly register mouse events when built with qt6?

[Rexbas]

I have no idea but I am trying to compile with qt6 right now.

[Rexbas]

It seems that the behavior of glReadPixels(...) is different but I don't know why or how to fix it.

FreeCAD/src/Gui/NaviCube.cpp

Lines 936 to 937 in eb3e83b

	glReadPixels(2 * x + m_CubeWidgetSize, 2 * y + m_CubeWidgetSize, 1, 1,
	GL_RGBA, GL_UNSIGNED_BYTE, &pixels);

[adrianinsaval]

could it be related to dpi scaling?

[Rexbas]

Don't know if it is dpi scaling.

If I write the QtGLFramebufferObject to a file by inserting this code:

auto img = m_PickingFramebuffer->toImage();
img.save(QString::fromStdString("test.png"));

here:

FreeCAD/src/Gui/NaviCube.cpp

Line 930 in eb3e83b

Then with qt5 I get this:

It might be hard to see but it is the navigation cube in dark red on a black background. This image is 800x800 pixels when I set navigation cube size to 400.

But with qt6 I get this:

This is also a 800x800 image but the content of the image is clearly not right.

So I think something is wrong with QtGLFramebufferObject* m_PickingFramebuffer. I don't know how to fix.

[YakoYakoYokuYoku]

I'm currently investigating this issue, from my observations this is split in two problems. One is that there's no mouse interaction with the navigation cube, so this means that at least one of SoQt or Qt6 is the culprit. The other is that reading from the framebuffer object returns invalid data, @Rexbas from what I can check is that QOpenGLFramebufferObject hasn't changed its semantics essentially since Qt5, so it must another thing.

[YakoYakoYokuYoku]

Could be related coin3d/soqt#80.

[Rexbas]

I think it is one problem. The mouse interaction with the navigation cube is not working because it can't decide which face is hovered/selected in NaviCubeImplementation::pickFace which is caused by the different behavior in the frame buffer.