On my setup:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel (0x8086)
Device: Mesa Intel(R) HD Graphics 530 (SKL GT2) (0x1912)
Version: 20.1.5
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
eglCreateWindowSurface with the sRGB flag fails with EGL_BAD_MATCH.
Bumping the ALPHA_SIZE from 1 to 8 seems to make the driver happy
again.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A single EGL display may be shared among several contexts. Don't
eglTerminate a context display when destroying the context.
Updates gio#144
Signed-off-by: Elias Naur <mail@eliasnaur.com>
At least one Samsung S9 device ignores the sRGB setting if the context
wasn't created with alpha in its attributes.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
I've resisted relying on pkg-config in the hope that hard-coded include and
library paths would suffice. However, apart from having to work around some
distro-specific differences, building with hardcoded include paths fails when
building on a buildroot:
x86_64-buildroot-linux-gnu-gcc: ERROR: unsafe header/library path used in cross-compilation: '-I/usr/include/wayland'
(see #91)
Andri mentions a workaround (prefixing paths with "="), but that doesn't seem
to work on the BSDs.
Let's see how pkg-config fares. It's an extra dependency, but it promises to keep
us isolated from the varying paths on Linux distrobutions.
Updates #91
Signed-off-by: Elias Naur <mail@eliasnaur.com>
EGL is window system agnostic, but its egl.h header includex X11
headers by default. Use the MESA_EGL_NO_X11_HEADERS define to avoid
it, fixing the "nox11" build for systems without X11 headers installed.
Fixes#91
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The error message is not appropriate where there are multiple backends,
and there's a much better chance Gio will run with the direct3d backend
where no external DLLs are required.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The srgb package was recently created to contain just the sRGB
emulation, but the names weren't shortened accordingly.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This is a refactoring change to prepare for another gpu.Backend
implementations.
Notably, app/loop.go no longer imports gpu/gl.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
A recent change made the OpenGL functions an interface of the functions
required for the implementation of GPU, a renderer for Gio operations.
That allowed for running Gio on external systems where OpenGL is
available.
However, to allow for non-OpenGL flavored backends such as Vulkan,
Metal and Direct3D, this change introduces Backend for the high-level
operations required by GPU. This change also adds a concrete backend
to package gl.
Type Backend is a first cut heavily based on OpenGL. Future changes will add
more backends, where the Backend interface quite possibly will need refinement.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The rendering implementation is needed for using Gio UI with external
window libraries such as GLFW. Expose it in the new package gpu.
Updates #26
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We'd like to support Gio using a different renderer binding than
the builtin. A first step is to define the Functions interface
in package gl, and extract the concrete implementations to a
separate package.
Updates #26
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Currently the golang.org/x/sys package is missing the Pipe2 call for OpenBSD.
The call exists on OpenBSD, it just isn't exposed.
This diff was tested buy adding the Pipe2 call and setting:
go mod edit -replace=golang.org/x/sys=/pat/to/modified/sys
Signed-off-by: Aaron Bieber <aaron@bolddaemon.com>
Issue #77 seems to be caused by eglGetDisplay returning a zero
EGLDisplay, yet eglGetError returns EGL_SUCCESS. Since EGLDisplay
is not necessary a pointer type, the zero value may be valid.
Updates #77
Signed-off-by: Elias Naur <mail@eliasnaur.com>
EGL contexts don't need locking, so their Lock and Unlock methods
are empty. Remove them and add them where necessary instead.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of calling from the low level context into the window
for its surface and dimensions, add a Context.MakeCurrent method
that does it directly.
The result is simpler and clearer logic. For example, synchronization
is obviously no longer needed. It wasn't necessary before, but the
reason was unclear.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur