mainnika
/
weston
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3486 Commits
1 Branch
0 Tags
13 MiB
Tag: Branch: Tree: c68b1085ed
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'c68b1085ed'
${ noResults }
weston/src/pixman-renderer.c

754 lines
21 KiB
Raw Normal View History Unescape

Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
/*
* Copyright © 2012 Intel Corporation
* Copyright © 2013 Vasily Khoruzhick <anarsoul@gmail.com>
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
* that the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of the copyright holders not be used in
* advertising or publicity pertaining to distribution of the software
* without specific, written prior permission. The copyright holders make
* no representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
* SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
* RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
* CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
configure.ac: Enable AC_USE_SYSTEM_EXTENSIONS AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar macros to expose the largest extent of functionality supported by the underlying system. This is required since these macros are often limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually on some systems hide declarations which are not part of the X/Open spec. Since this goes into config.h rather than the command line, ensure all source is consistently including config.h before anything else, including system libraries. This doesn't need to be guarded by a HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org modular transition. Signed-off-by: Daniel Stone <daniel@fooishbar.org> [pq: rebased and converted more files]
11 years ago
#include "config.h"
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
#include <errno.h>
#include <stdlib.h>
#include "pixman-renderer.h"
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
#include <linux/input.h>
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
struct pixman_output_state {
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
void *shadow_buffer;
pixman_image_t *shadow_image;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_image_t *hw_buffer;
};
struct pixman_surface_state {
pixman_image_t *image;
struct weston_buffer_reference buffer_ref;
};
struct pixman_renderer {
struct weston_renderer base;
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
int repaint_debug;
pixman_image_t *debug_color;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
};
static inline struct pixman_output_state *
get_output_state(struct weston_output *output)
{
return (struct pixman_output_state *)output->renderer_state;
}
static inline struct pixman_surface_state *
get_surface_state(struct weston_surface *surface)
{
return (struct pixman_surface_state *)surface->renderer_state;
}
static inline struct pixman_renderer *
get_renderer(struct weston_compositor *ec)
{
return (struct pixman_renderer *)ec->renderer;
}
static int
pixman_renderer_read_pixels(struct weston_output *output,
pixman_format_code_t format, void *pixels,
uint32_t x, uint32_t y,
uint32_t width, uint32_t height)
{
struct pixman_output_state *po = get_output_state(output);
pixman-renderer: Fix read_pixels for screen recorder The old code had an off-by-one error on the y coordinate where it says height - (cur_y - y). And it does the vflipping of the *destination* buffer, whereas what is really needed is to vflip the whole source buffer. This only affects when you read out part of the image, such as when using the screen recoder. Also, instead of doing the flipping manually we just let pixman handle it.
11 years ago
pixman_transform_t transform;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_image_t *out_buf;
if (!po->hw_buffer) {
errno = ENODEV;
return -1;
}
out_buf = pixman_image_create_bits(format,
width,
height,
pixels,
(PIXMAN_FORMAT_BPP(format) / 8) * width);
pixman-renderer: Fix read_pixels for screen recorder The old code had an off-by-one error on the y coordinate where it says height - (cur_y - y). And it does the vflipping of the *destination* buffer, whereas what is really needed is to vflip the whole source buffer. This only affects when you read out part of the image, such as when using the screen recoder. Also, instead of doing the flipping manually we just let pixman handle it.
11 years ago
/* Caller expects vflipped source image */
pixman_transform_init_translate(&transform,
pixman_int_to_fixed (x),
pixman_int_to_fixed (y - pixman_image_get_height (po->hw_buffer)));
pixman_transform_scale(&transform, NULL,
pixman_fixed_1,
pixman_fixed_minus_1);
pixman_image_set_transform(po->hw_buffer, &transform);
pixman_image_composite32(PIXMAN_OP_SRC,
po->hw_buffer, /* src */
NULL /* mask */,
out_buf, /* dest */
0, 0, /* src_x, src_y */
0, 0, /* mask_x, mask_y */
0, 0, /* dest_x, dest_y */
pixman_image_get_width (po->hw_buffer), /* width */
pixman_image_get_height (po->hw_buffer) /* height */);
pixman_image_set_transform(po->hw_buffer, NULL);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_image_unref(out_buf);
return 0;
}
compositor: Support output/buffer scaling If you specify e.g. scale=2 in weston.ini an output section for the X11 backend we automatically upscale all normal surfaces by this amount. Additionally we respect a buffer_scale set on the buffer to mean that the buffer is already in a scaled form. This works with both the gl and the pixman renderer. The non-X backends compile and work, but don't support changing the output scale (they do downscale as needed due to buffer_scale though). This also sends the new "scale" and "done" events on wl_output, making clients aware of the scale.
11 years ago
static void
box_scale(pixman_box32_t *dst, int scale)
{
dst->x1 *= scale;
dst->x2 *= scale;
dst->y1 *= scale;
dst->y2 *= scale;
}
static void
scale_region (pixman_region32_t *region, int scale)
{
pixman_box32_t *rects, *scaled_rects;
int nrects, i;
if (scale != 1) {
rects = pixman_region32_rectangles(region, &nrects);
scaled_rects = calloc(nrects, sizeof(pixman_box32_t));
for (i = 0; i < nrects; i++) {
scaled_rects[i] = rects[i];
box_scale(&scaled_rects[i], scale);
}
pixman_region32_clear(region);
pixman_region32_init_rects (region, scaled_rects, nrects);
free (scaled_rects);
}
}
pixman renderer: respect output position Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
static void
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
transform_region (pixman_region32_t *region, int width, int height, enum wl_output_transform transform)
pixman renderer: respect output position Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
{
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_box32_t *rects, *transformed_rects;
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
int nrects, i;
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
if (transform == WL_OUTPUT_TRANSFORM_NORMAL)
return;
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
rects = pixman_region32_rectangles(region, &nrects);
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
transformed_rects = calloc(nrects, sizeof(pixman_box32_t));
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
for (i = 0; i < nrects; i++) {
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
switch (transform) {
default:
case WL_OUTPUT_TRANSFORM_NORMAL:
transformed_rects[i].x1 = rects[i].x1;
transformed_rects[i].y1 = rects[i].y1;
transformed_rects[i].x2 = rects[i].x2;
transformed_rects[i].y2 = rects[i].y2;
break;
case WL_OUTPUT_TRANSFORM_90:
transformed_rects[i].x1 = height - rects[i].y2;
transformed_rects[i].y1 = rects[i].x1;
transformed_rects[i].x2 = height - rects[i].y1;
transformed_rects[i].y2 = rects[i].x2;
break;
case WL_OUTPUT_TRANSFORM_180:
transformed_rects[i].x1 = width - rects[i].x2;
transformed_rects[i].y1 = height - rects[i].y2;
transformed_rects[i].x2 = width - rects[i].x1;
transformed_rects[i].y2 = height - rects[i].y1;
break;
case WL_OUTPUT_TRANSFORM_270:
transformed_rects[i].x1 = rects[i].y1;
transformed_rects[i].y1 = width - rects[i].x2;
transformed_rects[i].x2 = rects[i].y2;
transformed_rects[i].y2 = width - rects[i].x1;
break;
case WL_OUTPUT_TRANSFORM_FLIPPED:
transformed_rects[i].x1 = width - rects[i].x2;
transformed_rects[i].y1 = rects[i].y1;
transformed_rects[i].x2 = width - rects[i].x1;
transformed_rects[i].y2 = rects[i].y2;
break;
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
transformed_rects[i].x1 = height - rects[i].y2;
transformed_rects[i].y1 = width - rects[i].x2;
transformed_rects[i].x2 = height - rects[i].y1;
transformed_rects[i].y2 = width - rects[i].x1;
break;
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
transformed_rects[i].x1 = rects[i].x1;
transformed_rects[i].y1 = height - rects[i].y2;
transformed_rects[i].x2 = rects[i].x2;
transformed_rects[i].y2 = height - rects[i].y1;
break;
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
transformed_rects[i].x1 = rects[i].y1;
transformed_rects[i].y1 = rects[i].x1;
transformed_rects[i].x2 = rects[i].y2;
transformed_rects[i].y2 = rects[i].x2;
break;
}
}
pixman_region32_clear(region);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_region32_init_rects (region, transformed_rects, nrects);
free (transformed_rects);
}
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
static void
region_global_to_output(struct weston_output *output, pixman_region32_t *region)
{
pixman_region32_translate(region, -output->x, -output->y);
transform_region (region, output->width, output->height, output->transform);
Rename current, origin, scale, origin_scale This patch renames that fields to have consistent names.
11 years ago
scale_region (region, output->current_scale);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
#define D2F(v) pixman_double_to_fixed((double)v)
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
static void
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
repaint_region(struct weston_view *ev, struct weston_output *output,
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_region32_t *region, pixman_region32_t *surf_region,
pixman_op_t pixman_op)
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
{
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
struct pixman_renderer *pr =
(struct pixman_renderer *) output->compositor->renderer;
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
struct pixman_surface_state *ps = get_surface_state(ev->surface);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
struct pixman_output_state *po = get_output_state(output);
pixman_region32_t final_region;
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
float view_x, view_y;
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_transform_t transform;
pixman_fixed_t fw, fh;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
/* The final region to be painted is the intersection of
* 'region' and 'surf_region'. However, 'region' is in the global
* coordinates, and 'surf_region' is in the surface-local
* coordinates
*/
pixman_region32_init(&final_region);
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
if (surf_region) {
pixman_region32_copy(&final_region, surf_region);
/* Convert from surface to global coordinates */
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (!ev->transform.enabled) {
pixman_region32_translate(&final_region, ev->geometry.x, ev->geometry.y);
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
} else {
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
weston_view_to_global_float(ev, 0, 0, &view_x, &view_y);
pixman_region32_translate(&final_region, (int)view_x, (int)view_y);
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
}
/* We need to paint the intersection */
pixman_region32_intersect(&final_region, &final_region, region);
} else {
/* If there is no surface region, just use the global region */
pixman_region32_copy(&final_region, region);
}
/* Convert from global to output coord */
region_global_to_output(output, &final_region);
/* And clip to it */
pixman_image_set_clip_region32 (po->shadow_image, &final_region);
/* Set up the source transformation based on the surface
compositor: Support output/buffer scaling If you specify e.g. scale=2 in weston.ini an output section for the X11 backend we automatically upscale all normal surfaces by this amount. Additionally we respect a buffer_scale set on the buffer to mean that the buffer is already in a scaled form. This works with both the gl and the pixman renderer. The non-X backends compile and work, but don't support changing the output scale (they do downscale as needed due to buffer_scale though). This also sends the new "scale" and "done" events on wl_output, making clients aware of the scale.
11 years ago
position, the output position/transform/scale and the client
specified buffer transform/scale */
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_transform_init_identity(&transform);
compositor: Support output/buffer scaling If you specify e.g. scale=2 in weston.ini an output section for the X11 backend we automatically upscale all normal surfaces by this amount. Additionally we respect a buffer_scale set on the buffer to mean that the buffer is already in a scaled form. This works with both the gl and the pixman renderer. The non-X backends compile and work, but don't support changing the output scale (they do downscale as needed due to buffer_scale though). This also sends the new "scale" and "done" events on wl_output, making clients aware of the scale.
11 years ago
pixman_transform_scale(&transform, NULL,
Rename current, origin, scale, origin_scale This patch renames that fields to have consistent names.
11 years ago
pixman_double_to_fixed ((double)1.0/output->current_scale),
pixman_double_to_fixed ((double)1.0/output->current_scale));
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
fw = pixman_int_to_fixed(output->width);
fh = pixman_int_to_fixed(output->height);
switch (output->transform) {
default:
case WL_OUTPUT_TRANSFORM_NORMAL:
case WL_OUTPUT_TRANSFORM_FLIPPED:
break;
case WL_OUTPUT_TRANSFORM_90:
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
pixman_transform_rotate(&transform, NULL, 0, -pixman_fixed_1);
pixman_transform_translate(&transform, NULL, 0, fh);
break;
case WL_OUTPUT_TRANSFORM_180:
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
pixman_transform_rotate(&transform, NULL, -pixman_fixed_1, 0);
pixman_transform_translate(&transform, NULL, fw, fh);
break;
case WL_OUTPUT_TRANSFORM_270:
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
pixman_transform_rotate(&transform, NULL, 0, pixman_fixed_1);
pixman_transform_translate(&transform, NULL, fw, 0);
break;
}
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
switch (output->transform) {
case WL_OUTPUT_TRANSFORM_FLIPPED:
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
pixman_transform_scale(&transform, NULL,
pixman_int_to_fixed (-1),
pixman_int_to_fixed (1));
pixman_transform_translate(&transform, NULL, fw, 0);
break;
}
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_transform_translate(&transform, NULL,
pixman_double_to_fixed (output->x),
pixman_double_to_fixed (output->y));
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (ev->transform.enabled) {
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
/* Pixman supports only 2D transform matrix, but Weston uses 3D,
* so we're omitting Z coordinate here
*/
pixman_transform_t surface_transform = {{
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
{ D2F(ev->transform.matrix.d[0]),
D2F(ev->transform.matrix.d[4]),
D2F(ev->transform.matrix.d[12]),
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
},
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
{ D2F(ev->transform.matrix.d[1]),
D2F(ev->transform.matrix.d[5]),
D2F(ev->transform.matrix.d[13]),
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
},
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
{ D2F(ev->transform.matrix.d[3]),
D2F(ev->transform.matrix.d[7]),
D2F(ev->transform.matrix.d[15]),
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
}
}};
pixman_transform_invert(&surface_transform, &surface_transform);
pixman_transform_multiply (&transform, &surface_transform, &transform);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
} else {
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_transform_translate(&transform, NULL,
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
pixman_double_to_fixed ((double)-ev->geometry.x),
pixman_double_to_fixed ((double)-ev->geometry.y));
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
fw = pixman_int_to_fixed(ev->geometry.width);
fh = pixman_int_to_fixed(ev->geometry.height);
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
switch (ev->surface->buffer_transform) {
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
case WL_OUTPUT_TRANSFORM_FLIPPED:
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
pixman_transform_scale(&transform, NULL,
pixman_int_to_fixed (-1),
pixman_int_to_fixed (1));
pixman_transform_translate(&transform, NULL, fw, 0);
break;
}
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
switch (ev->surface->buffer_transform) {
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
default:
case WL_OUTPUT_TRANSFORM_NORMAL:
case WL_OUTPUT_TRANSFORM_FLIPPED:
break;
case WL_OUTPUT_TRANSFORM_90:
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
pixman_transform_rotate(&transform, NULL, 0, pixman_fixed_1);
pixman_transform_translate(&transform, NULL, fh, 0);
break;
case WL_OUTPUT_TRANSFORM_180:
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
pixman_transform_rotate(&transform, NULL, -pixman_fixed_1, 0);
pixman_transform_translate(&transform, NULL, fw, fh);
break;
case WL_OUTPUT_TRANSFORM_270:
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
pixman_transform_rotate(&transform, NULL, 0, -pixman_fixed_1);
pixman_transform_translate(&transform, NULL, 0, fw);
break;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
compositor: Support output/buffer scaling If you specify e.g. scale=2 in weston.ini an output section for the X11 backend we automatically upscale all normal surfaces by this amount. Additionally we respect a buffer_scale set on the buffer to mean that the buffer is already in a scaled form. This works with both the gl and the pixman renderer. The non-X backends compile and work, but don't support changing the output scale (they do downscale as needed due to buffer_scale though). This also sends the new "scale" and "done" events on wl_output, making clients aware of the scale.
11 years ago
pixman_transform_scale(&transform, NULL,
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
pixman_double_to_fixed ((double)ev->surface->buffer_scale),
pixman_double_to_fixed ((double)ev->surface->buffer_scale));
compositor: Support output/buffer scaling If you specify e.g. scale=2 in weston.ini an output section for the X11 backend we automatically upscale all normal surfaces by this amount. Additionally we respect a buffer_scale set on the buffer to mean that the buffer is already in a scaled form. This works with both the gl and the pixman renderer. The non-X backends compile and work, but don't support changing the output scale (they do downscale as needed due to buffer_scale though). This also sends the new "scale" and "done" events on wl_output, making clients aware of the scale.
11 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_image_set_transform(ps->image, &transform);
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (ev->transform.enabled || output->current_scale != ev->surface->buffer_scale)
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_image_set_filter(ps->image, PIXMAN_FILTER_BILINEAR, NULL, 0);
else
pixman_image_set_filter(ps->image, PIXMAN_FILTER_NEAREST, NULL, 0);
pixman_image_composite32(pixman_op,
ps->image, /* src */
NULL /* mask */,
po->shadow_image, /* dest */
0, 0, /* src_x, src_y */
0, 0, /* mask_x, mask_y */
0, 0, /* dest_x, dest_y */
pixman_image_get_width (po->shadow_image), /* width */
pixman_image_get_height (po->shadow_image) /* height */);
if (pr->repaint_debug)
pixman_image_composite32(PIXMAN_OP_OVER,
pr->debug_color, /* src */
NULL /* mask */,
po->shadow_image, /* dest */
0, 0, /* src_x, src_y */
0, 0, /* mask_x, mask_y */
0, 0, /* dest_x, dest_y */
pixman_image_get_width (po->shadow_image), /* width */
pixman_image_get_height (po->shadow_image) /* height */);
pixman_image_set_clip_region32 (po->shadow_image, NULL);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_region32_fini(&final_region);
}
static void
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
draw_view(struct weston_view *ev, struct weston_output *output,
pixman_region32_t *damage) /* in global coordinates */
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
{
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
struct pixman_surface_state *ps = get_surface_state(ev->surface);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
/* repaint bounding region in global coordinates: */
pixman_region32_t repaint;
/* non-opaque region in surface coordinates: */
pixman_region32_t surface_blend;
/* No buffer attached */
if (!ps->image)
return;
pixman_region32_init(&repaint);
pixman_region32_intersect(&repaint,
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
&ev->transform.boundingbox, damage);
pixman_region32_subtract(&repaint, &repaint, &ev->clip);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
if (!pixman_region32_not_empty(&repaint))
goto out;
if (output->zoom.active) {
weston_log("pixman renderer does not support zoom\n");
goto out;
}
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
/* TODO: Implement repaint_region_complex() using pixman_composite_trapezoids() */
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (ev->transform.enabled &&
ev->transform.matrix.type != WESTON_MATRIX_TRANSFORM_TRANSLATE) {
repaint_region(ev, output, &repaint, NULL, PIXMAN_OP_OVER);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
} else {
/* blended region is whole surface minus opaque region: */
pixman_region32_init_rect(&surface_blend, 0, 0,
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
ev->geometry.width, ev->geometry.height);
pixman_region32_subtract(&surface_blend, &surface_blend, &ev->surface->opaque);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (pixman_region32_not_empty(&ev->surface->opaque)) {
repaint_region(ev, output, &repaint, &ev->surface->opaque, PIXMAN_OP_SRC);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
if (pixman_region32_not_empty(&surface_blend)) {
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
repaint_region(ev, output, &repaint, &surface_blend, PIXMAN_OP_OVER);
pixman-renderer: handle surface transform matrix properly Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
pixman_region32_fini(&surface_blend);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
out:
pixman_region32_fini(&repaint);
}
static void
repaint_surfaces(struct weston_output *output, pixman_region32_t *damage)
{
struct weston_compositor *compositor = output->compositor;
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
struct weston_view *view;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
Split the geometry information from weston_surface out into weston_view The weston_surface structure is split into two structures: * The weston_surface structure storres everything required for a client-side or server-side surface. This includes buffers; callbacks; backend private data; input, damage, and opaque regions; and a few other bookkeeping bits. * The weston_view structure represents an entity in the scenegraph and storres all of the geometry information. This includes clip region, alpha, position, and the transformation list as well as all of the temporary information derived from the geometry state. Because a view, and not a surface, is a scenegraph element, the view is what is placed in layers and planes. There are a few things worth noting about the surface/view split: 1. This is *not* a modification to the protocol. It is, instead, a modification to Weston's internal scenegraph to allow a single surface to exist in multiple places at a time. Clients are completely unaware of how many views to a particular surface exist. 2. A view is considered a direct child of a surface and is destroyed when the surface is destroyed. Because of this, the view.surface pointer is always valid and non-null. 3. The compositor's surface_list is replaced with a view_list. Due to subsurfaces, building the view list is a little more complicated than it used to be and involves building a tree of views on the fly whenever subsurfaces are used. However, this means that backends can remain completely subsurface-agnostic. 4. Surfaces and views both keep track of which outputs they are on. 5. The weston_surface structure now has width and height fields. These are populated when a new buffer is attached before surface.configure is called. This is because there are many surface-based operations that really require the width and height and digging through the views didn't work well. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
wl_list_for_each_reverse(view, &compositor->view_list, link)
if (view->plane == &compositor->primary_plane)
draw_view(view, output, damage);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
static void
copy_to_hw_buffer(struct weston_output *output, pixman_region32_t *region)
{
struct pixman_output_state *po = get_output_state(output);
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_region32_t output_region;
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_region32_init(&output_region);
pixman_region32_copy(&output_region, region);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
region_global_to_output(output, &output_region);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_image_set_clip_region32 (po->hw_buffer, &output_region);
pixman_image_composite32(PIXMAN_OP_SRC,
po->shadow_image, /* src */
NULL /* mask */,
po->hw_buffer, /* dest */
0, 0, /* src_x, src_y */
0, 0, /* mask_x, mask_y */
0, 0, /* dest_x, dest_y */
pixman_image_get_width (po->hw_buffer), /* width */
pixman_image_get_height (po->hw_buffer) /* height */);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
pixman-renderer: Fix up transform handling Rather than storing the shadow_image in the untransformed space and rotating on copy to hw_buffer we store both on the transformed space. This means a copy between them is a straight copy, and that apps supplying correctly transformed surface buffers need not change them. We also correctly handle all output transform including the previously unhandled flipped ones, as well as client supplied buffer_transforms (which were previously ignored). We also simplify the actual rendering by just converting any damage region to output coordinates and set it on a clip and composite the whole buffer, letting pixman do the rectangle handling. This means we always do all the transforms, including the surface positioning as a pixman_image transform. This simplifies the code and sets us up for handling scaling at a later stage. The transform looks complicated, but in practice it ends up being an integer translation almost always, so it will hit the pixman fastpaths.
11 years ago
pixman_image_set_clip_region32 (po->hw_buffer, NULL);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
}
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
static void
pixman_renderer_repaint_output(struct weston_output *output,
pixman_region32_t *output_damage)
{
struct pixman_output_state *po = get_output_state(output);
if (!po->hw_buffer)
return;
repaint_surfaces(output, output_damage);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
copy_to_hw_buffer(output, output_damage);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_region32_copy(&output->previous_damage, output_damage);
wl_signal_emit(&output->frame_signal, output);
/* Actual flip should be done by caller */
}
static void
pixman_renderer_flush_damage(struct weston_surface *surface)
{
/* No-op for pixman renderer */
}
static void
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
pixman_renderer_attach(struct weston_surface *es, struct weston_buffer *buffer)
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
{
struct pixman_surface_state *ps = get_surface_state(es);
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
struct wl_shm_buffer *shm_buffer;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_format_code_t pixman_format;
weston_buffer_reference(&ps->buffer_ref, buffer);
if (ps->image) {
pixman_image_unref(ps->image);
ps->image = NULL;
}
if (!buffer)
return;
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
shm_buffer = wl_shm_buffer_get(buffer->resource);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
if (! shm_buffer) {
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
weston_log("Pixman renderer supports only SHM buffers\n");
weston_buffer_reference(&ps->buffer_ref, NULL);
return;
}
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
switch (wl_shm_buffer_get_format(shm_buffer)) {
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
case WL_SHM_FORMAT_XRGB8888:
pixman_format = PIXMAN_x8r8g8b8;
break;
case WL_SHM_FORMAT_ARGB8888:
pixman_format = PIXMAN_a8r8g8b8;
break;
pixman-renderer: Add support for SHM buffers in RGB565 format
11 years ago
case WL_SHM_FORMAT_RGB565:
pixman_format = PIXMAN_r5g6b5;
break;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
default:
weston_log("Unsupported SHM buffer format\n");
weston_buffer_reference(&ps->buffer_ref, NULL);
return;
break;
}
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
buffer->shm_buffer = shm_buffer;
buffer->width = wl_shm_buffer_get_width(shm_buffer);
buffer->height = wl_shm_buffer_get_height(shm_buffer);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
ps->image = pixman_image_create_bits(pixman_format,
Add a weston_buffer structure to replace wl_buffer This commit adds a weston_buffer structure to replace wl_buffer. This way we can hold onto buffers by just their resource. In order to do this, the every renderer.attach function has to fill in the weston_buffer.width and weston_buffer.height fields. Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
11 years ago
buffer->width, buffer->height,
wl_shm_buffer_get_data(shm_buffer),
wl_shm_buffer_get_stride(shm_buffer));
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
}
static int
pixman_renderer_create_surface(struct weston_surface *surface)
{
struct pixman_surface_state *ps;
ps = calloc(1, sizeof *ps);
if (!ps)
return -1;
surface->renderer_state = ps;
return 0;
}
static void
pixman_renderer_surface_set_color(struct weston_surface *es,
float red, float green, float blue, float alpha)
{
struct pixman_surface_state *ps = get_surface_state(es);
pixman_color_t color;
color.red = red * 0xffff;
color.green = green * 0xffff;
color.blue = blue * 0xffff;
color.alpha = alpha * 0xffff;
if (ps->image) {
pixman_image_unref(ps->image);
ps->image = NULL;
}
ps->image = pixman_image_create_solid_fill(&color);
}
static void
pixman_renderer_destroy_surface(struct weston_surface *surface)
{
struct pixman_surface_state *ps = get_surface_state(surface);
if (ps->image) {
pixman_image_unref(ps->image);
ps->image = NULL;
}
weston_buffer_reference(&ps->buffer_ref, NULL);
free(ps);
}
renderer: introduce destroy callback Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
static void
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman_renderer_destroy(struct weston_compositor *ec)
{
free(ec->renderer);
ec->renderer = NULL;
}
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
static void
input: Merge wl_seat into weston_seat
12 years ago
debug_binding(struct weston_seat *seat, uint32_t time, uint32_t key,
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
void *data)
{
struct weston_compositor *ec = data;
struct pixman_renderer *pr = (struct pixman_renderer *) ec->renderer;
pr->repaint_debug ^= 1;
if (pr->repaint_debug) {
pixman_color_t red = {
0x3fff, 0x0000, 0x0000, 0x3fff
};
pr->debug_color = pixman_image_create_solid_fill(&red);
} else {
pixman_image_unref(pr->debug_color);
weston_compositor_damage_all(ec);
}
}
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
WL_EXPORT int
pixman_renderer_init(struct weston_compositor *ec)
{
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
struct pixman_renderer *renderer;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
pixman-renderer: Initialize pixman-renderer struct with zeros Othrewise a crash may happen because of an unitialized value of the create_view field.
11 years ago
renderer = calloc(1, sizeof *renderer);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
if (renderer == NULL)
return -1;
pixman-renderer: don't forget to initialize the debug fields Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61930
12 years ago
renderer->repaint_debug = 0;
renderer->debug_color = NULL;
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
renderer->base.read_pixels = pixman_renderer_read_pixels;
renderer->base.repaint_output = pixman_renderer_repaint_output;
renderer->base.flush_damage = pixman_renderer_flush_damage;
renderer->base.attach = pixman_renderer_attach;
renderer->base.create_surface = pixman_renderer_create_surface;
renderer->base.surface_set_color = pixman_renderer_surface_set_color;
renderer->base.destroy_surface = pixman_renderer_destroy_surface;
renderer->base.destroy = pixman_renderer_destroy;
ec->renderer = &renderer->base;
compositor: add capability flag for arbitrary surface rotation The upcoming rpi-renderer cannot handle arbitrary rotations. Introduce Weston capability bits, and add a bit for arbitrary rotation. GL and Pixman renderers support it. Shell or any other module must not produce surface transformations with rotation, if the capability bit is not set. Do not register the surface rotation binding in desktop shell, if arbitary rotation is not supported. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
11 years ago
ec->capabilities |= WESTON_CAP_ROTATION_ANY;
compositor: add capability CAPTURE_YFLIP Both GL and pixman renderer (pixman probably only because GL did?) return the screen capture image as y-flipped, therefore Weston y-flips it again. However, the future rpi-renderer can produce only right-way-up (non-flipped) screen captures, and does not need an y-flip. Add a capability flag for y-flip, which the rpi-renderer will not set, to get screen captures the right way up. The wcap recording code needs yet another temporary buffer for the non-flipped case, since the WCAP format is flipped, and the code normally overwrites the input image as it compresses it. This becomes difficult, if the compressor is supposed to flip while processing. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
11 years ago
ec->capabilities |= WESTON_CAP_CAPTURE_YFLIP;
pixman-renderer: Add repaint debugging feature Add 'R' as a debug shortcut that highlights repainted regions.
12 years ago
weston_compositor_add_debug_binding(ec, KEY_R,
debug_binding, ec);
pixman-renderer: Add support for SHM buffers in RGB565 format
11 years ago
wl_display_add_shm_format(ec->wl_display, WL_SHM_FORMAT_RGB565);
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
return 0;
}
WL_EXPORT void
pixman_renderer_output_set_buffer(struct weston_output *output, pixman_image_t *buffer)
{
struct pixman_output_state *po = get_output_state(output);
if (po->hw_buffer)
pixman_image_unref(po->hw_buffer);
po->hw_buffer = buffer;
if (po->hw_buffer) {
output->compositor->read_format = pixman_image_get_format(po->hw_buffer);
pixman_image_ref(po->hw_buffer);
}
}
WL_EXPORT int
pixman_renderer_output_create(struct weston_output *output)
{
struct pixman_output_state *po = calloc(1, sizeof *po);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
int w, h;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
if (!po)
return -1;
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
/* set shadow image transformation */
Rename current, origin, scale, origin_scale This patch renames that fields to have consistent names.
11 years ago
w = output->current_mode->width;
h = output->current_mode->height;
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
po->shadow_buffer = malloc(w * h * 4);
if (!po->shadow_buffer) {
free(po);
return -1;
}
po->shadow_image =
pixman_image_create_bits(PIXMAN_x8r8g8b8, w, h,
po->shadow_buffer, w * 4);
if (!po->shadow_image) {
free(po->shadow_buffer);
free(po);
return -1;
}
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
output->renderer_state = po;
return 0;
}
WL_EXPORT void
pixman_renderer_output_destroy(struct weston_output *output)
{
struct pixman_output_state *po = get_output_state(output);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
pixman_image_unref(po->shadow_image);
pixman-renderer: Don't unreference NULL hw_buffer image If the buffer for an output was never set, or was reset to NULL at some point, destroying the renderer output private would cause a crash.
12 years ago
if (po->hw_buffer)
pixman_image_unref(po->hw_buffer);
pixman-renderer: Move shadow buffer into renderer The X11 backend uses a shadow buffer to be able to support transformed outputs. However, this belongs in the renderer, since otherwise this code would have to be copied into every backend that uses the pixman renderer and supports transformed outputs.
12 years ago
po->shadow_image = NULL;
Implement pixman renderer This renderer could be used when there's no graphic accelerator available, for example in (future) KMS and fbdev backends. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
12 years ago
po->hw_buffer = NULL;
free(po);
}