GitLab

A rudimentary job, just to ensure Windows builds don't go south.

The FreeGLUT dependencies are derived from the Linux headers plus a .def
file, to avoid any further downloads whatsoever.

v2: Quote all bash variable expansions and treat unset vars as errors,
per Eric Engestrom.

We can pack multiple triangle-strips into a single draw, by inserting
degenerate triangles between them. This should be a big win in terms of
CPU usage.

To avoid inserting needless degenerate triangles to invert face-winding,
we can manually invert the order of the back-face as well as emit the
inner face last. This ensures every strip starts with the right
face-winding.
Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collbora.com>

glad is a more modern, cleaner, and flexible alternative to GLEW.  In
particular it has first-class citizen support for OpenGL ES end EGL.

Glad can't be used just for defines.  For old demos which only need
defines, we could bundle Khronos glext, but for now place the necessary
defines on gl_wrap.h

This sample is broken, it's not easy to fix, and it's too
complicated/niche to be worth the hassle.

GCC < 5 defaults to -std=gnu89, failing to build:

glxgears.c: In function 'init':
glxgears.c:413: error: 'for' loop initial declaration used outside C99 mode

Fixes: 8c73555b

 ("glxgears / wglgears: adjust colors for sRGB")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>

glxgears smooth-shades the inner face, so let's do that here as well for
visual parity.
Reviewed-by: Adam Jackson <ajax@redhat.com>

glxgears uses the default value for ambient light, which is 0.2. We
should do the same. This makes these two demos look the same.
Reviewed-by: Adam Jackson <ajax@redhat.com>

There's two things that differs about the geometry position of this port
of glxgears:

1. The camera is moved back by the wrong amount.
2. The projection matrix is computed the wrong way.

So let's remedy this, and make the rendering closer to the original.
Reviewed-by: Adam Jackson <ajax@redhat.com>

As a bonus feature you can set negative values if your driver supports
GLX_EXT_swap_control_tear, though heaven help you if your renderer is so
slow that that improves things.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>

I don't know what I was thinking; we don't have support for
stereo-rendering in wglgears.

This reverts commit 8bf5a21b

.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

Without this, the colors have a very different look, making the red more
orange. This adjust the colors to give the same appearance.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

wglgears already have this, so let's also add it for glxgears!
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Even if the window is not yet displayed, the object still exists and
takes up memory. So let's destroy it before recreating.

Fixes: 14688d84

 ("wglgears.c: add -srgb option")
Reviewed-by: Brian Paul <brianp@vmware.com>

When adding support for the "-geometry" option, I forgot to update the
second call to CreateWindowEx, meaning it only respected this option
when not using srgb or multisampling. Let's fix that.

Fixes: 16c9a130

 ("wglgears: add geometry option")
Reviewed-by: Brian Paul <brianp@vmware.com>

This fix wasn't a great idea; even if it seems to work fine on modern
Windows versions, the documentation says that SetPixelFormat can only be
set once per window. And worse, Mesa's OpenGL32.DLL emulation code seems
to depend on this, ignoring any consecutive calls. This means that with
Mesa, we get no multisampling here.

So, let's revert this, and instead follow what the docs say.

This reverts commit 27813895

.
Reviewed-by: Brian Paul <brianp@vmware.com>

In order to get the correct screen-resolution on hidpi displays, we need
to mark the process as dpi-aware first.
Reviewed-by: Brian Paul <brianp@vmware.com>

This seems to work fine on NVIDIA, but seems to report incorrect results
on Intel drivers. Reading the WGL_EXT_swap_control specification, this
seems like subtle driver-bug, and not an application problem, so let's
do this anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>

This helper allows us to check if a WGL-extension is supported or not.
It will be used in the next commit.
Reviewed-by: Brian Paul <brianp@vmware.com>

This allows the animation to be paused and resumed, just like with
glxgears.
Reviewed-by: Brian Paul <brianp@vmware.com>

If we're too strict with our requirements, we should properly report the
issue. We shouldn't assert, and we should list the requirements so it's
easy to understand why.
Reviewed-by: Brian Paul <brianp@vmware.com>

When we re-created the window, we accidentally leaked the old window.
It's not so easy to notice, because it's invisible, but it's still there
and taking up some memory.

But there's more problems; when I recently added the -geometry switch,
I missed the extra CreateWindowEx call, meaning this call didn't respect
the x and y offset.

But instead of fixing these things indevidually, let's take a step back
here. There's no reason to re-create the window here in the first place.
We can just set a new pixel-format on hDC and re-create hRC instead.

This makes the code both easier to maintain, and squashes a couple of
bugs.
Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

This code contains a lot of code that can't realistically fail; these
things can only fail on incorrect input, or under memory pressure. We're
passing correct input, and we're not yet at a point where memory
pressure is really possible.

So for the sake of readability, let's remove some overly paranoid
error-checking. It's not like these error-messages are all that useful
to most users, compared to running this in a debugger anyway.

This makes the code reasier to read, and makes it easier to add
meaningful error-checking where it actually matters in the future.
Reviewed-by: Brian Paul <brianp@vmware.com>

Two things:
- We spell "Usage" with an upper-case 'u'.
- We print usage to stdout, not stderr.
Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

This copies the logic from glxgears, omitting the rotating-state,
because we have no such option (yet).

In order to do this, we also need to swap out our timer. In order to
keep things nice and easy, we can use timeGetTime(), but set the minumum
period before the event-loop.

And for the timing-calculation, this is a lot better with proper
resolution anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

This seems a bit arbitrary, we don't generally print messages about
internals like this. So let's drop it.
Reviewed-by: Brian Paul <brianp@vmware.com>

It seems different GPU drivers behave differently in the case of
per-thread DPI-awareness, causing incorrect rendering on drivers like
the NVIDIA-driver. This is probably related to some internal threading
in the drivers, and is probably a subtle driver-bug.

In either case, setting per-process DPI awareness seems to do the trick.
It doesn't matter to us if we're doing per process or per thread, so
let's just go with the more robust solution.

Fixes: 7fa3a433 ("wglgears: mark application as dpi-aware")

This makes rendering nice and crisp on high-dpi systems. Since we're not
doing any layouting or anything, we can just claim to be aware without
doing much.

We keep the current window-size when the DPI changes, because the size
is specified in pixels, so it seems more useful to keep that as-is.
Reviewed-by: Brian Paul <brianp@vmware.com>

The parser isn't exactly identical with XParseGeometry, but should be
close enough for general use.
Reviewed-by: Brian Paul <brianp@vmware.com>

Reviewed-by: Brian Paul <brianp@vmware.com>

This makes the code look a bit more like the similar code for glxgears.
There's no good reason to do this differently for these two
applications.
Reviewed-by: Brian Paul <brianp@vmware.com>