Split main.c into smaller files

This commit is contained in:
Johan Malm 2019-12-26 21:37:31 +00:00
parent a194e07809
commit 52f81e4a39
8 changed files with 539 additions and 513 deletions

164
output.c Normal file
View file

@ -0,0 +1,164 @@
#include "labwc.h"
/*
* Used to move all of the data necessary to render a surface from the
* top-level frame handler to the per-surface render function.
*/
struct render_data {
struct wlr_output *output;
struct wlr_renderer *renderer;
struct tinywl_view *view;
struct timespec *when;
};
static void render_decorations(struct wlr_output *output, struct tinywl_view *view) {
if (!view->surface)
return;
if (view->type != LAB_XWAYLAND_VIEW)
return;
if (!is_toplevel(view))
return;
struct wlr_box box = {
.x = view->x - XWL_WINDOW_BORDER,
.y = view->y - XWL_TITLEBAR_HEIGHT - XWL_WINDOW_BORDER,
.width = view->surface->current.width + 2 * XWL_WINDOW_BORDER,
.height = view->surface->current.height + XWL_TITLEBAR_HEIGHT +
2 * XWL_WINDOW_BORDER,
};
float matrix[9];
wlr_matrix_project_box(matrix, &box, WL_OUTPUT_TRANSFORM_NORMAL, 0,
output->transform_matrix);
float color[] = { 0.2, 0.2, 0.7, 0.9 };
wlr_render_quad_with_matrix(view->server->renderer, color, matrix);
}
static void render_surface(struct wlr_surface *surface,
int sx, int sy, void *data) {
/* This function is called for every surface that needs to be rendered. */
struct render_data *rdata = data;
struct tinywl_view *view = rdata->view;
struct wlr_output *output = rdata->output;
/* We first obtain a wlr_texture, which is a GPU resource. wlroots
* automatically handles negotiating these with the client. The underlying
* resource could be an opaque handle passed from the client, or the client
* could have sent a pixel buffer which we copied to the GPU, or a few other
* means. You don't have to worry about this, wlroots takes care of it. */
struct wlr_texture *texture = wlr_surface_get_texture(surface);
if (texture == NULL) {
return;
}
/* The view has a position in layout coordinates. If you have two displays,
* one next to the other, both 1080p, a view on the rightmost display might
* have layout coordinates of 2000,100. We need to translate that to
* output-local coordinates, or (2000 - 1920). */
double ox = 0, oy = 0;
wlr_output_layout_output_coords(
view->server->output_layout, output, &ox, &oy);
ox += view->x + sx;
oy += view->y + sy;
/* We also have to apply the scale factor for HiDPI outputs. This is only
* part of the puzzle, TinyWL does not fully support HiDPI. */
struct wlr_box box = {
.x = ox * output->scale,
.y = oy * output->scale,
.width = surface->current.width * output->scale,
.height = surface->current.height * output->scale,
};
/*
* Those familiar with OpenGL are also familiar with the role of matricies
* in graphics programming. We need to prepare a matrix to render the view
* with. wlr_matrix_project_box is a helper which takes a box with a desired
* x, y coordinates, width and height, and an output geometry, then
* prepares an orthographic projection and multiplies the necessary
* transforms to produce a model-view-projection matrix.
*
* Naturally you can do this any way you like, for example to make a 3D
* compositor.
*/
float matrix[9];
enum wl_output_transform transform =
wlr_output_transform_invert(surface->current.transform);
wlr_matrix_project_box(matrix, &box, transform, 0,
output->transform_matrix);
/* This takes our matrix, the texture, and an alpha, and performs the actual
* rendering on the GPU. */
wlr_render_texture_with_matrix(rdata->renderer, texture, matrix, 1);
/* This lets the client know that we've displayed that frame and it can
* prepare another one now if it likes. */
wlr_surface_send_frame_done(surface, rdata->when);
}
void output_frame(struct wl_listener *listener, void *data) {
/* This function is called every time an output is ready to display a frame,
* generally at the output's refresh rate (e.g. 60Hz). */
struct tinywl_output *output =
wl_container_of(listener, output, frame);
struct wlr_renderer *renderer = output->server->renderer;
struct timespec now;
clock_gettime(CLOCK_MONOTONIC, &now);
/* wlr_output_attach_render makes the OpenGL context current. */
if (!wlr_output_attach_render(output->wlr_output, NULL)) {
return;
}
/* The "effective" resolution can change if you rotate your outputs. */
int width, height;
wlr_output_effective_resolution(output->wlr_output, &width, &height);
/* Begin the renderer (calls glViewport and some other GL sanity checks) */
wlr_renderer_begin(renderer, width, height);
float color[4] = {0.3, 0.3, 0.3, 1.0};
wlr_renderer_clear(renderer, color);
/* Each subsequent window we render is rendered on top of the last. Because
* our view list is ordered front-to-back, we iterate over it backwards. */
struct tinywl_view *view;
wl_list_for_each_reverse(view, &output->server->views, link) {
if (!view->mapped) {
/* An unmapped view should not be rendered. */
continue;
}
struct render_data rdata = {
.output = output->wlr_output,
.view = view,
.renderer = renderer,
.when = &now,
};
render_decorations(output->wlr_output, view);
/* This calls our render_surface function for each surface among the
* xdg_surface's toplevel and popups. */
if (view->type == LAB_XDG_SHELL_VIEW) {
wlr_xdg_surface_for_each_surface(view->xdg_surface,
render_surface, &rdata);
} else if (view->type == LAB_XWAYLAND_VIEW) {
render_surface(view->xwayland_surface->surface, 0, 0,
&rdata);
}
}
/* Hardware cursors are rendered by the GPU on a separate plane, and can be
* moved around without re-rendering what's beneath them - which is more
* efficient. However, not all hardware supports hardware cursors. For this
* reason, wlroots provides a software fallback, which we ask it to render
* here. wlr_cursor handles configuring hardware vs software cursors for you,
* and this function is a no-op when hardware cursors are in use. */
wlr_output_render_software_cursors(output->wlr_output, NULL);
/* Conclude rendering and swap the buffers, showing the final frame
* on-screen. */
wlr_renderer_end(renderer);
wlr_output_commit(output->wlr_output);
}