Commit Graph

8 Commits

Author SHA1 Message Date
Elias Naur 18b4442393 all: remove Z buffer support
It is no longer needed by any rendering backend.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-08-08 13:47:37 +01:00
Elias Naur 7d84e419c9 gpu,gpu/headless,app/internal/wm: add explicit RenderTarget API
Both the OpenGL and the Direct3D API are stateful and gpu.GPU renders to
the render target current when Frame is called.

Modern GPU API such as Metal don't have a concept of a current render
target, and the target even changes each frame.

Add RenderTarget and add an explicit target argument to GPU.Frame as
well as the underlying driver.Device.BeginFrame.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-08-08 13:45:23 +01:00
Elias Naur 0bdc2e0432 app,app/internal/wm: fold context MakeCurrent/ReleaseCurrent into Lock/Unlock
While here, make context Refresh useful and remove the redundant
MakeCurrent from the window loop.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-08-08 13:53:19 +02:00
Elias Naur 7da315eb2b app,app/internal/wm: release OpenGL context after use
Otherwise, making a context current on another thread may result in
an EGL_BAD_ACCESS error.

Fixes gio#248

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-07-27 09:42:34 +02:00
Elias Naur ca5a05bb35 internal/d3d11,app/internal/wm: add Direct3D11 leak reporting
Updates gio#245

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-07-18 17:57:38 +01:00
Elias Naur 0e592f8bc6 app,app/internal/wm: [macOS] refresh context on display change
The NSViewGlobalFrameDidChangeNotification notification is documented to
be fired every time [NSOpenGLContext update] needs to be called.
However, the notification fails to fire on my setup when a window is
moved to a display with a different pixel scale, which leads to
incorrectly sized output.

This change gets rid of the notification and updates the context before
every frame.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-06-12 20:07:52 +02:00
Elias Naur 8611894b4b app,app/internal/wm: introduce app.Window.Run and use it internally
app.Window implements a method for safely running functions against the
underlying native window through the driverFuncs channel. However, the
functions still run in a different goroutine than the one driving the
native event loop, which forces the implementations in package wm to do
complicated synchronization.

A previous change added a mechanism to run functions in the native event
loop thread. The macOS port needed this functionality, but with some
care it can be generalized. That's what this change does through the
new Run method.

The advantage is that the thread switch dance is now confined to
app.Window, with the help of a generic wm.Driver.Wakeup method. All
other Driver methods can then assume they run on their event loop
threads.

Run is exported because it is also needed for programs that use
Windows configured with CustomRenderer to control their own rendering.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-05-18 19:59:01 +01:00
Elias Naur 7059b6284a app/internal/wm: rename confusing app/internal/window
Package wm (for "window manager") is a better fit for the package, and
distinguishes it from the low-level package windows for the Windows API.

Signed-off-by: Elias Naur <mail@eliasnaur.com>
2021-03-06 14:28:57 +01:00