graphics window opens off-screen

[rewolff]

From a performance perspective, the current strategy: "develop with a certain hardware target" is quite successful. You get to optimize for "reasonable" hardware.

When software has hardware requirements and I require the software, then I'll go out of my way to acquire said hardware or change things around to accommodate the software.

However, as a language I'd like to try "curv" for a few minutes before I actually invest in hardware and trouble to get it running. The "compilation phase" was painless. Good job!

But when it comes to running curv: I get nothing. Turns out I don't have the required hardware.

So... IMHO, at some point in time, before it is too late(*), you'll need to bite the bullet and "port" the software to "generic" hardware so that it can at least run to give people a taste.

I haven't looked into how deep "requires direct access to the GPU hardware" goes. With the "requires nvidia closed-source drivers" I would think that things still work through an API.

If that API is something like opengl, then only minor differences or optimizations are "not working enough" on other hardware and drivers. Implementing workarounds (Agreed: keep them out of the main sources!) to allow say Nouveau to run the tool.

What I mean with "keep them out of the sources" is that if say "minix strcpy" has a bug, you should not start littering the code with

#ifdef MINIX
  my_strcpy (...);
#else
  strcpy (...);
#endif
 // Note that it is almost impossible to type endif or else directives in github, 
// as they get changed to  issue numbers immediately. 

but a better way would be to hide this stuff in some header:

// compatibility.h
#ifdef MINIX
#define strcpy my_strcpy
#endif

This keeps the main code clean and readable as it should be but allows the code to compile and run on lesser systems.

Just for reference: I have a system with compatible nvidia hardware and Nouveau driver. It is just that I am very happy that it runs stably and I don' t want to risk disturbing that as I use the machine on a daily basis.

Stretch goal: I'd want it to run on the raspberry pi as I think my young niece should do 3D modeling.

(*) Too late would be when your code gets too intimately tied to the specific hardware that was at first the target.

[doug-moen]

I need to understand your bug better. Please run curv --version and paste the output.

Also, please give a specific example of what doesn't work when you try to run Curv using the Nouveau driver. I don't test on Nouveau, but Curv shouldn't be completely broken with that driver. There does seem to be a GPU related bug that affects some people, but so far I haven't been able to reproduce it or isolate it. Maybe your problem is related.

My goal is to support any GPU manufactured in 2012 or later, as long as it has up to date drivers that aren't too buggy. Older GPUs may also work. I'm not writing hardware specific code.

Curv currently uses OpenGL 3.3, but AFAIK the Raspberry Pi only supports OpenGL 2.0 right now due to outdated drivers. Even if I did get manage to get Curv running on OpenGL 2.0, then some Curv programs would not work due to missing OpenGL features. Software rendering of OpenGL 3.3 is possible on the Pi, but it's quite slow. Eric Anholt of Broadcom is developing an open source OpenGL driver based on Mesa that will fully support Curv on Raspberry Pi (https://gitlab.freedesktop.org/anholt). So my Raspberry Pi strategy is to wait for this driver.

The problem right now with AMD GPUs is bugs in the open source Mesa driver that affect Curv (and which also break Blender). https://bugs.freedesktop.org/show_bug.cgi?id=105371

[rewolff]

Well.... I don't know what to expect. I expected something similar to "openscad" that I'd get an empty workspace. I compiled curv from git, downloaded yesterday (or maybe the daybefore,) with "last change" about 8 days earlier.

The --version reports:

Curv: 0.4-71-g635527b7
Compiler: gcc 7.4.0
Kernel: Linux 4.15.0-46-generic x86_64
GPU: nouveau, NVD9
OpenGL: 3.1 Mesa 18.2.8

When I run ../release/curv orbit.curv in the examples directory, nothing happens except 3D shape 3.5×3.5×1.5

[doug-moen]

Normally what should happen is that a graphics window will open displaying the orbit model. If there is an error opening the graphics window, then an error message should be displayed. If there is a problem with the GPU driver, then the graphics window should open, but the contents will turn black, or some garbage will be displayed. If you type ctrl-C to interrupt the curv command, then curv will exit and the graphics window will close.

If you don't see the window, and you don't see an error message, then that's a new kind of problem. After curv prints

3D shape 3.5×3.5×1.5

do you get a shell prompt back immediately, or is the curv program still running? I wonder if this is a window manager issue. Is it possible that the graphics window is hidden under another window?

[rewolff]

Funny timestamps on the comments! Time travel! (Thanks for answering my question before I asked :-) )

No prompt, Curv keeps running and consumes on the order of 4% CPU. How long should I wait? If the render takes 1 minute and I don't get a window before that, then I didn't wait long enough....

OK. Your guess is almost right! Thanks!

The window opens OFF-screen: I have two 1920x1080 monitors, one landscape and one portrait. so my virtual desktop is 3000x1920. To align the two monitors my landscape monitor starts at y = 520, so I have a "not-visible" 1920x520+0+0 rectangle above my (most used) landscape monitor. The curv window opens at negative coordinates such that the window-dressings happen outside the acessible coordinates (when I'm at home I can use a hotkey to move the window, I can't do that from here because then I move the "window with my home desktop")

I use the "sawfish" window manager. I've started using features of "twm" in the early nineties. Those I find "essential" for a window manager. So when new and more modern window managers come along I upgrade whenever the essential stuff is available. This means I've upgraded to tvtwm, fvwm and now sawfish. All the others lack the one feature I can't do without.

[doug-moen]

So you have a dead zone in your virtual desktop, and windows created in this dead zone are not visible.

The best place to fix this bug is in your window manager, or in the software you use to configure multiple monitors.

I'm using the GLFW library to create the graphics window. I'm letting GLFW decide where to position the new window. GLFW, in turn, delegates this decision to the native window manager (running on X11, Wayland, or whatever you are using). GLFW supports the concept of multiple monitors, and gives me the ability to specify which monitor to create the window in (I just pick the default monitor). It sounds like your setup combines both of your physical monitors into a single virtual monitor with a dead spot. If that is what is happening, and if GLFW doesn't know you have two monitors, then it might be impossible to fix this bug at the application level.

[rewolff]

Dear Doug, When you have multiple monitors,that are not the same height and next to each other, you always get a virtual desktop that has "unused areas". My window manager knows about this and almost all programs open up on the visible part. Just a very very select few misbehave and end up in the not-visible part.

How do I find out if GLFW knows about my monitors? glxgears indeed also opens up in the complete top-left of the virtual screen.

[doug-moen]

I'm curious about how well Curv works on your system under Nouveau. Here are some simple tests:

• curv -x circle : display a yellow circle. A simple 2D model. If this doesn't work, likely nothing else will either.
• curv -x cube : display a yellow cube

[rewolff]

It works fine. Now that I can see the results. Even the animated examples work. Orbit is a cube and a sphere playing around.

What doesn't work is that 8?x12? blocks of screen pixels that have an edge turn black. "edge" here is where the normal points towards the camera point changes into that the normal points away from the camera. This doesn't happen for "simple" cases, only when there is also another part of the scene behind that edge. So in the field-of-sines when you change the viewpoint to be so low that the hills obscure part of the shape behind it, that's when you start to get the black squares.

Oh, one more thing: When I start curv, I see a short "flash" on my screen. For one refresh of the monitor something is visible in the visible area of my monitor and then the window is quickly moved off the visible area.

[doug-moen]

What doesn't work is that 8?x12? blocks of screen pixels that have an edge turn black.

I haven't seen this problem, but it sounds like a GPU driver issue. I can sort of guess what is going on, and I might be able to come up with a configuration parameter that would mitigate the problem. You are getting better results from Nouveau than I did the last time I tried it.

When I start curv, I see a short "flash" on my screen.

So the window is created in a visible location, then something moves it off screen. Now I know what the problem is. Try updating Curv and see if the bug is fixed. Use:

make update
make
sudo make install

[rewolff]

This guy has the same problem with the occasional application opening offscreen: http://dpod.kakelbont.ca/2017/12/11/finding-and-moving-off-screen-applications-in-gnome-3-ubuntu-17-10/ Here another one with a different workaround. (I use an even different workaround). http://blog.vogella.com/2013/06/02/ubuntu-how-to-move-an-application-which-is-displayed-offscreen/

It happens with a few different applications, but when it happens, it always happens with that application. It happens with a few window managers, but then on those window managers, most applications just work fine.

I think it is something like: "pass -1, -1 as the preferred location to have the window manager decide" where some window managers also interpret 0,0 as the "you do it", while others (mine) interpret that as "sure, 0,0 if you want!". This might be hidden in some intermediate library, that translate the API "you decide" into the bad 0,0 instead of the -1-1...

[rewolff]

make update says: "target update not found" or something like that. Git pull pulled in around 1000 lines of changes by the looks of it. git submodule update did something like "checked out version xxx" on some submodule.

The window now comes up in the visible area. The 4x8 black boxes are still there.

The facts:

make: *** No rule to make target 'update'.  Stop.
...
47 files changed, 369 insertions(+), 239 deletions(-)
assurancetourix:~/curv> git submodule update
Submodule path 'extern/glfw': checked out 'b0796109629931b6fa6e449c15a177845256a407'

I'm working my way through the examples. Three down, 1 example written by myself now, but I still haven't typed "make install" yet.

[doug-moen]

Sorry, make update is a new feature, I guess it was added after you cloned my repo. You have it now.