Mouse clicks and atoms in 3D view sometimes misaligned

[matterhorn103]

Avogadro version: (please complete the following information from the About box):

• Avogadrolibs: any recent, e.g. 1.102.1
• Qt: 6.9.3

Desktop version: (please complete the following information):

• OS: Fedora 42
• Flatpak

Describe the bug

Sometimes, after launch, the position clicked is not the position where atoms appear. The atoms instead appear below and to the left of the clicked position.

It seems to be some mathematical calculation that's at fault, because though the offset varies, it is not random, and is clearly a function of the position on screen.

The atoms also appear further away than usual.

It's definitely about misinterpretation/mistranslation of the coordinates, as right-click can also be used to delete atoms, as long as the same offset is used.

It's an odd bug, primarily because it only appears in certain circumstances:

• On Fedora (on openSUSE Tumbleweed I haven't observed it, at least not within memory)
• With the Flatpak (the AppImage is fine)
• When the initial window is smaller than the full screen
• After launch
• Before anything is done that causes the size of the 3D view to change

As soon as anything is done that causes the 3D view to change dimensions, the positions of the atoms on the screen change (they move up and right, get closer, and subsequent clicks result in correct positions). Behaviour is always correct from that point onwards, no matter what, and the bug only reoccurs after closing and relaunching, so far as I can tell.

Things that trigger the reversion to correct behaviour therefore include the following:

• Maximizing the window
• Resizing the window
• Changing to a tool with a wider tool pane than the Draw Tool (e.g. the Manipulation Tool, but not the Navigation Tool)

Note that the issue has been present for a little while, and is still present in at least 1.102.1.

[matterhorn103]

A video to demonstrate:

Screencast_20251112_165251.webm

Note also the way that some atoms are cut off sharply. Essentially it looks like the rendered 3D view is not correctly filling the 3D view pane itself.

[matterhorn103]

Ah, I've found the explanation – it's to do with the scaling settings. Fedora vs Tumbleweed is not what makes the difference, it's the fact that my laptop (Fedora) uses 125% scaling and my desktop (Tumbleweed) has no scaling applied. I can reproduce the issue on both systems by changing the scaling settings.

[matterhorn103]

The discrepancy between the rendered size and the pane size at different scaling factors in the images below shows that

1. it is not much related to the window size relative to the screen
2. the discrepancy actually reduces at higher scaling factors (and presumably disappears at 200%)

125%

125% with a smaller window

150%

175%

I guess that, when running in the Flatpak environment, the renderer is not getting some information about the scaling that the Qt window management processes are. Or, the information is available but not being looked for or accounted for.

Why this should be Flatpak-specific I don't know, but I'll investigate whether this is a known problem.

[matterhorn103]

Looking at the code, the first thing that looks to be a candidate for the origin of the problem is that GLWidget gets the scaling (pixelRatio) as part of GLWidget::resizeGL(), which then propagates it to the renderer:

void GLWidget::resizeGL(int width_, int height_)
{
  float pixelRatio = window()->windowHandle()->devicePixelRatio();
  m_renderer.setPixelRatio(pixelRatio);
  m_renderer.resize(width_, height_);
}

void GLRenderer::resize(int width, int height)
{
  if (!m_valid)
    return;

  glViewport(0, 0, static_cast<GLint>(width), static_cast<GLint>(height));
  m_camera.setViewport(width, height);
  m_overlayCamera.setViewport(width, height);
  m_solidPipeline.resize(width, height);
}

void GLRenderer::setPixelRatio(float ratio)
{
  m_solidPipeline.setPixelRatio(ratio);
}

The Qt docs say that resizeGL() gets called when a widget is shown for the first time, but it also says that initializeGL() is called before resizeGL(), and GLWidget::initializeGL() seems to kick off a chain of events for which it seems like the pixel ratio might be quite important:

void GLWidget::initializeGL()
{
  m_renderer.initialize();
  if (!m_renderer.isValid())
    emit rendererInvalid();
}

void GLRenderer::initialize()
{
  GLenum result = glewInit();
  m_valid = (result == GLEW_OK || result == GLEW_ERROR_NO_GLX_DISPLAY);
  if (!m_valid) {
    m_error += "GLEW could not be initialized.\n";
    return;
  }

  if (!GLEW_VERSION_2_0) {
    m_error += "GL version 2.0 is not supported by your graphics driver.\n";
    m_valid = false;
    return;
  }

  m_solidPipeline.initialize();
}

SolidPipeline seems to do quite a bit at initialization:

void SolidPipeline::initialize()
{
  initializeFramebuffer(&d->renderFBO, &d->renderTexture, &d->depthTexture);

  glGenBuffers(1, &d->screenVBO);
  glBindBuffer(GL_ARRAY_BUFFER, d->screenVBO);
  glBufferData(GL_ARRAY_BUFFER, sizeof(s_fullscreenQuad), s_fullscreenQuad,
               GL_STATIC_DRAW);

  d->screenVertexShader.setType(Shader::Vertex);
  d->screenVertexShader.setSource(solid_vs);
  if (!d->screenVertexShader.compile())
    std::cout << d->screenVertexShader.error() << std::endl;

  d->firstFragmentShader.setType(Shader::Fragment);
  d->firstFragmentShader.setSource(solid_first_fs);
  if (!d->firstFragmentShader.compile())
    std::cout << d->firstFragmentShader.error() << std::endl;

  d->firstStageShaders.attachShader(d->screenVertexShader);
  d->firstStageShaders.attachShader(d->firstFragmentShader);
  if (!d->firstStageShaders.link())
    std::cout << d->firstStageShaders.error() << std::endl;
}

and while it's doing all that it's using an m_pixelRatio of 1.0, because that's the default it's created with. Only thing is, it doesn't seem like any those functions would be affected by the value of m_pixelRatio...

Thing is, when a resize happens post-launch, everything takes its correct size. That presumably means the logic in GLWidget::resizeGL() for obtaining the pixel ratio and applying it is correct, it's just not being used at initial render time.

I also have no idea why the AppImage and Flatpak would behave differently in this respect. Maybe it's a Qt issue?

[ghutchis]

I put in some bits to deal with high-resolution screens (e.g. Mac Retina) and we found that some of it is handled by Qt now. But I don't think much of it gets tested beyond scaling ratios of 1.0 and 2.0.

I'll take a deeper look this week, but it might be hard to reproduce since I only have 1.0 and 2.0 screens.