- 02 Aug, 2021 1 commit
-
-
Jordan Justen authored
To update your local repository to use the new default branch, these commands may help: $ git fetch origin $ git checkout master $ git branch -m main $ git branch --set-upstream-to=origin/main $ git remote set-head origin --auto Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
- 24 Mar, 2021 1 commit
-
-
Jose Fonseca authored
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.
-
- 08 Oct, 2020 1 commit
-
-
Erik Faye-Lund authored
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>
-
- 16 Sep, 2020 5 commits
-
-
Jose Fonseca authored
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
-
Jose Fonseca authored
-
Jose Fonseca authored
-
Jose Fonseca authored
This sample is broken, it's not easy to fix, and it's too complicated/niche to be worth the hassle.
-
Jose Fonseca authored
-
- 15 Sep, 2020 1 commit
-
-
Jan Beich authored
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>
-
- 14 Sep, 2020 3 commits
-
-
Erik Faye-Lund authored
glxgears smooth-shades the inner face, so let's do that here as well for visual parity. Reviewed-by:
Adam Jackson <ajax@redhat.com>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
- 11 Sep, 2020 1 commit
-
-
Adam Jackson authored
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>
-
- 04 Aug, 2020 1 commit
-
-
Erik Faye-Lund authored
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>
-
- 10 Jul, 2020 4 commits
-
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
- 06 Jul, 2020 2 commits
-
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
wglgears already have this, so let's also add it for glxgears! Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
- 07 May, 2020 3 commits
-
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
- 20 Apr, 2020 10 commits
-
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
This allows the animation to be paused and resumed, just like with glxgears. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
Two things: - We spell "Usage" with an upper-case 'u'. - We print usage to stdout, not stderr. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
- 17 Apr, 2020 3 commits
-
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
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>
-
- 16 Apr, 2020 4 commits
-
-
Erik Faye-Lund authored
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")
-
Erik Faye-Lund authored
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>
-
Erik Faye-Lund authored
The parser isn't exactly identical with XParseGeometry, but should be close enough for general use. Reviewed-by:
Brian Paul <brianp@vmware.com>
-
Erik Faye-Lund authored
Reviewed-by:
Brian Paul <brianp@vmware.com>
-