Lines disappear if are in near orthogonal position

[ghost]

System information

SolveSpace version: 3.0~4d1e1341

Operating system: Debian 9.x "stretch"

Expected behavior

All lines should be rendered correctly in SolveSpace.

Actual behavior

Lines (no matter what stile it use) that in are near orthogonal position to display (monitor plane) disappear. Look like rendering issue.

Additional information

[whitequark]

I can't reproduce this. What OpenGL renderer and video card do you have?

[ghost]

OpenGL Version 2.1 Mesa 13.0.6 (GLSL 1.20)

Gallium 0.4 on ATI RS600 - X.Org R300 Project

[whitequark]

The minimum version of OpenGL required by SolveSpace master branch is 3.2. Actually, I would not expect it to work on 2.1 at all (you should get an error from GTK, but instead you get a compatibility profile for some reason; likely a bug), so you are already quite lucky.

Generally, I do not consider it a priority to support graphics cards 10 years old and older (like RS600), for the same reasons I do not consider it a priority to support operating systems last updated 10 years ago and earlier (like Windows XP). You are welcome to figure out how to fix this glitch yourself (and if the fix doesn't negatively impact anything newer, I'll include it), but I won't be spending any time on it myself.

(And of course, you can always keep using SolveSpace 2.)

[Evil-Spirit]

@whitequark Can we just introduce cmdline option to switch OpenGL 1/3?

[whitequark]

@Evil-Spirit Not on Linux. You cannot request a compatibility context explicitly through GTK 3, it always first tries to get 3.2+ core profile, and only if it cannot fulfill that, it falls back to the newest supported compatibility profile.

On Windows we don't have this problem because ANGLE can translate our OpenGL ES to DirectX 9, which is way older than OpenGL 3.2. (Though we only run on Vista+, so we use DirectX 11.) On macOS we don't have this problem because all macOS versions still supported by Apple have OpenGL 3.2 core profie natively.

[whitequark]

I guess it's possible to detect the fallback to a compatibility context and dynamically change our renderer implementation to use OpenGL 1. But this means that now I have to test every change that affects graphics twice: first for all the normal operating systems and configurations, and then the second time for OpenGL 1. Which is a lot of work just to support outdated Linux distributins with ancient video cards.

And I think we have some things that are just completely broken in OpenGL 1 because they need shaders (but I don't remember what those were).

[ghost]

But this means that now I have to test every change that affects graphics twice: first for all the normal operating systems and configurations, and then the second time for OpenGL 1. Which is a lot of work just to support outdated Linux distributins with ancient video cards.
And I think we have some things that are just completely broken in OpenGL 1 because they need shaders (but I don't remember what those were).

I'm ready to help you with testing.

Please, just do not drop OpenGL1 support!

[whitequark]

OK, so I have spent a very desolate 30 minutes looking into this issue, and this is something that will only ever manifest on very old ATI GPUs on Linux because (apparently) their selection of GL and GLSL version is quite broken.

Please, just do not drop OpenGL1 support!

There is no OpenGL 1 support on Linux in SolveSpace for something like a year, everything is rendered using OpenGL 3.2. And in fact, in most cases it is not possible, period, to use OpenGL 1 with GTK 3. The screenshots you posted above were rendered using OpenGL 3.2 calls.

In the extremely specific case where you (a) have a GPU that doesn't support OpenGL 3.2 and (b) your OS doesn't already use a software fallback like LLVMpipe because it uses compositing and (c) you use an ATI GPU, you're going to hit the paths in GTK and ATI drivers that end up creating an OpenGL context that's somewhere between OpenGL 2.1 and OpenGL 3.2 that has this sort of buggy rendering. Most people will never hit this. Anyone using an Intel or Nvidia GPU, or a GPU that's from 2009 or newer with a distro that ships with Mesa 10 or newer will never hit this.

So what you're saying is, because you have this awful ancient GPU with its awful drivers, you want every single person making a change to SolveSpace's OpenGL rendering code in the future to spend twice the amount of work it should take solely so that your awful ancient GPU renders the UI slightly better using OpenGL 1.

Sorry, the answer is no. The workarounds are to either use SolveSpace 2, or to run SolveSpace with LIBGL_ALWAYS_SOFTWARE=true environment variable set.