mrview: ROI edits deleted after two elements drawn

[fionaEyoung]

When drawing an ROI, I can draw a maximum of two elements before previously drawn elements start disappearing in a FIFO manner. So if I draw one rectangle, then a second, as soon as I click to draw a third, the first one vanishes.
This behaviour is limited to the current slice. So for example, if I fill an axial slice, then switch to a saggital slice (which now has a single filled line through it) and begin editing, after 1 edit the filled line will disappear. Switching back to the filled axial slice, just that line is erased, not the whole slice.

This behaviour persists regardless of

• drawing tool (brush / rectangle / fill)
• loading an existing ROI file vs creating a new one within mrview
• drawing or erasing
• single slice or orthoview
• background image

Here is an animation demonstrating the behaviour:

I have never had this problem with any other installations of MRtrix on other machines, only on my new M1 silicon Macbook Pro. I've also checked it isn't just a display issue: if I save the file, quit mrview and load the ROI again, the erased bits are still erased.

To Reproduce

1. Open any image in mrview and create a new ROI in the ROI editor
2. Choose a tool (e.g. brush) and click edit
3. Draw a shape
4. Draw another shape
5. Draw a third shape: the first one disappears
6. Draw another shape: the second one disappears
7. You get the picture

Platform/Environment/Version

• OS: MacOS 11.1
• MRtrix3 version 3.0.2-78-g430465d6 64 bit release version, built Mar 9 2021, using Eigen 3.3.9 (built from source)

---

Advanced debugging information

• Qt version: 5.15.2
• OpenGL info:

• mrview -exit -debug:

mrview -exit -debug
mrview: [DEBUG] No config file found at "/etc/mrtrix.conf"
mrview: [INFO] reading config file "/Users/fiona/.mrtrix.conf"...
mrview: [DEBUG] reading key/value file "/Users/fiona/.mrtrix.conf"...
mrview: [INFO] GL renderer:  Apple M1
mrview: [INFO] GL version:   4.1 Metal - 71.0.7
mrview: [INFO] GL vendor:    Apple
mrview: [DEBUG] loading font into OpenGL texture...
mrview: [DEBUG] compiling OpenGL vertex shader:
#version 330 core
layout(location = 0) in vec2 pos;
layout(location = 1) in vec2 font_pos;
uniform float scale_x;
uniform float scale_y;
out vec2 tex_coord;
void main () {
  gl_Position = vec4 (pos[0]*scale_x-1.0, pos[1]*scale_y-1.0, 0.0, 1.0);
  tex_coord = font_pos;
}

mrview: [DEBUG] compiling OpenGL fragment shader:
#version 330 core
in vec2 tex_coord;
uniform sampler2D sampler;
uniform float red, green, blue;
out vec4 color;
void main () {
  color.ra = texture (sampler, tex_coord).rg;
  color.rgb = color.r * vec3 (red, green, blue);
}

mrview: [DEBUG] font loaded

[fionaEyoung]

Behaviour reproduced on another M1 machine:

• MacOS 11.3.1
• MRtrix3 version 3.0.2
• Qt version 5.15.2
• mrview -exit -debug:

mrview: [DEBUG] No config file found at "/etc/mrtrix.conf"
mrview: [DEBUG] No config file found at "/Users/jon/.mrtrix.conf"
mrview: [INFO] GL renderer:  Apple M1
mrview: [INFO] GL version:   4.1 Metal - 71.5.9
mrview: [INFO] GL vendor:    Apple
mrview: [DEBUG] loading font into OpenGL texture...
mrview: [DEBUG] compiling OpenGL vertex shader:
#version 330 core
layout(location = 0) in vec2 pos;
layout(location = 1) in vec2 font_pos;
uniform float scale_x;
uniform float scale_y;
out vec2 tex_coord;
void main () {
  gl_Position = vec4 (pos0]*scale_x-1.0, pos[1]*scale_y-1.0, 0.0, 1.0);
  tex_coord = font_pos;
}

mrview: [DEBUG] compiling OpenGL fragment shader:
#version 330 core
in vec2 tex_coord;
uniform sampler2D sampler;
uniform float red, green, blue;
out vec4 color;
void main () {
  color.ra = texture (sampler, tex_coord).rg;
  color.rgb = color.r * vec3 (red, green, blue);
}

mrview: [DEBUG] font loaded

[jdtournier]

@bjeurissen, looks like we can add this issue to #2247 and #2281...

[jdtournier]

@fionaEyoung, thanks for the bug report. Unfortunately OpenGL support on the M1 seems to be somewhat buggy or incomplete. I'm not sure what we can do here until Apple decides to improve their drivers. The difference here compared to the other issues is that this code doesn't make use of geometry shaders, which is what seems to be causing problems elsewhere. It's just straight texture transfers, I'm not sure why that would be problematic on the M1...

[fionaEyoung]

@jdtournier No problem. I did consider adding it to the existing M1-related issues but like you say it seems like a different enough functionality that was going wrong, didn't want to clutter things :) I've since found some more strange behaviour when using the "copy from slice" functions, happy to describe in more detail if you think it would shed some light on the matter.

[jdtournier]

Thanks, feel free to describe these other issues, but it sounds like the same problem to me: issues with the glTexSubImage3D() call somewhere. Given we have no issues on other platforms, I'm inclined to think this is a problem with the OpenGL support on the M1, rather than an issue within our code as such. But there is always scope for our OpenGL handling to not be 100% standards-compliant - we sometimes find that certain operations are well supported on certain platforms but not others, and that this is because some implementations support non-standard behaviour better than others. More generally, it's hard for me to investigate without access to the actual physical device for testing...

[bjeurissen]

Thanks, feel free to describe these other issues, but it sounds like the same problem to me: issues with the glTexSubImage3D() call somewhere. Given we have no issues on other platforms, I'm inclined to think this is a problem with the OpenGL support on the M1, rather than an issue within our code as such. But there is always scope for our OpenGL handling to not be 100% standards-compliant - we sometimes find that certain operations are well supported on certain platforms but not others, and that this is because some implementations support non-standard behaviour better than others. More generally, it's hard for me to investigate without access to the actual physical device for testing...

@fionaEyoung, @jdtournier: Reproduced on my M1 machine as well 😭

@jdtournier: should I send you a M1 mac mini? 😁

[bjeurissen]

On Apple M1, with macOS 12.6.1 (21G217) and OpenGL renderer 4.1 Metal - 76.3, I can no longer reproduce this issue when building from source (3.0.3-464-g84e11a42) with Qt 5.15.6.

I can still reproduce the issue when using the version from the current binary installer (which was compiled for x86-64 rather than arm64).

[jdtournier]

That's great news. Couple of questions:

• do you still get the issue when building from source on x86-64 (i.e. not just using the binary installer)?
• how easy would it be to produce one of these universal binaries with both ARM & x86-64 versions included?