Yea looks like you are right. I thought the matrix in the vertex shader
was a final output one, but it is instead the projection to clipping
space. I would suspect even if you could mess with whatever is done to
convert clipping space to pixel space would just make it clip at the
wrong location
On Tue, Mar 10, 2015 at 12:01:53PM -0700, Bill Spitzak wrote:
>
>
> On 03/09/2015 11:41 PM, Pekka Paalanen wrote:
> >On Mon, 09 Mar 2015 11:13:20 -0700
> >Bill Spitzak wrote:
> >
> >>On 03/09/2015 06:34 AM, Pekka Paalanen wrote:
> >>
> >>>What performance concerns do you have?
> >>
> >>I suspect
Hey pq,
Glad to see this stuff finally look like landing ~1 year later. :-) My
reviewing ability on this code has decreased substantially since I wrote it
so I'm kind of trusting you to have tested it thuroughly and trusting
myself to have known what I was doing back then. That said,
Reviewed-by
On Tue, Mar 10, 2015 at 12:51 PM, Bill Spitzak wrote:
> This all looks really good to me.
>
> It is possible to avoid "GL coordinates" even in GL. Set the projection
> matrix to an ortho matrix:
>
> glMatrixMode(GL_PROJECTION);
> glLoadIdentity()
> glOrtho(0, width, height, 0, -1, 1);
> g
On Tue, Mar 10, 2015 at 6:01 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Move code into a new helper function. No changes.
>
> Signed-off-by: Pekka Paalanen
> Reviewed-By: Derek Foreman
> ---
> src/pixman-renderer.c | 31 ++-
> 1 file changed, 18 insertion
This all looks really good to me.
It is possible to avoid "GL coordinates" even in GL. Set the projection
matrix to an ortho matrix:
glMatrixMode(GL_PROJECTION);
glLoadIdentity()
glOrtho(0, width, height, 0, -1, 1);
glTranslate(-width/2, -height/2, 0);
glMatrixMode(GL_MODELVIEW);
I
Using the new pixman_image_t may be equivalent (I should check) but if
there is some speed problem it should be possible to get an arbitrary
subrectangle by making a new pixman_image_t directly from the buffer by
setting the stride to the full buffer stride and setting the origin and
the width
On 03/09/2015 11:34 PM, Pekka Paalanen wrote:
On Mon, 09 Mar 2015 10:56:23 -0700
Bill Spitzak wrote:
On 03/09/2015 01:20 AM, Pekka Paalanen wrote:
However, we already also have an exception to this in upstream: the
Wayland backend needs to draw the output window decorations.
Sorry can yo
On 03/09/2015 11:41 PM, Pekka Paalanen wrote:
On Mon, 09 Mar 2015 11:13:20 -0700
Bill Spitzak wrote:
On 03/09/2015 06:34 AM, Pekka Paalanen wrote:
What performance concerns do you have?
I suspect the worry was about allocating and freeing a temporary array,
but your idea of the caller pa
On 03/09/2015 10:32 PM, Jasper St. Pierre wrote:
Mouse input is reported in a 24.8 fixed-point format. Subpixel mouse
locations are entirely possible.
Yes events are doing this which is ok.
There is a problem that clients must round to the correct pixel. If the
rounding done by the client doe
... that only provide a unique libsystemd.pc file
---
configure.ac | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index d9d8d8f..561c380 100644
--- a/configure.ac
+++ b/configure.ac
@@ -347,8 +347,12 @@ AS_IF([test "x$have_systemd_login" = "
On 10/03/15 08:01 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Hi,
>
> as requested by Derek, here is a revised series from
> http://lists.freedesktop.org/archives/wayland-devel/2015-March/020440.html
>
> The major addition to the series is that I pulled selected patches from
> http://l
From: Pekka Paalanen
Change the region argument types in repaint_region(), moving the
final_region computation to the caller. The caller is in a better
position deciding if source clipping is needed or if it can be intersected
into the final_region via a simple translation. This avoids
surf_regio
From: Derek Foreman
We can greatly simplify weston_output_transform_coordinate now by simply
multiplying by the output matrix and converting the result to fixed point.
This patch fixes zoomed input behaviour on the nested backends (x11,
wayland) which use absolute input coordinates. And probably
From: Pekka Paalanen
A simple refactoring just to help readability.
Signed-off-by: Pekka Paalanen
Reviewed-By: Derek Foreman
---
src/pixman-renderer.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index 9612
From: Pekka Paalanen
Also remove the now dead code from weston_output_update_zoom().
Signed-off-by: Pekka Paalanen
---
src/zoom.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/zoom.c b/src/zoom.c
index 16d487d..c70a70c 100644
--- a/src/zoom.c
+++ b/src/zoom.c
From: Pekka Paalanen
Only needed in the source-clipped case, otherwise the boundingbox is
already doing the necessary clipping.
Signed-off-by: Pekka Paalanen
Reviewed-By: Derek Foreman
---
src/pixman-renderer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/pixman-renderer.c b
From: Pekka Paalanen
Move code from draw_view() into a new function draw_view_translated().
This new function is correct only if
view_transformation_is_translation().
The test for view->alpha is moved into draw_view_translated() too, so we
don't need to pass the pixman_op from draw_view(). The n
From: Jason Ekstrand
Previously, the zoom functions used GL coordinates natively which doesn't
work with the new output matrix calculations. This changes zoom to work in
pixel coordinates to match the new output matrix format. This also cleans
up the math in the zoom code substantially.
This p
From: Pekka Paalanen
Remove several fields from struct weston_output_zoom as a consequence of
removing animation_xy from it. Animation_xy was always empty, unused.
Animation_xy was likely used by text_cursor_position implementation, but
that was removed in commit a7af70436b7dccfacd736626d6719b3e
From: Jason Ekstrand
Previously, weston_output.matrix was in GL coordinates and therefore only
really useful for the GL backend.
This breaks zoom, which will be fixed by the following patch:
zoom: Use pixels instead of GL coordinates
[Pekka: added a comment to compositor.h, message]
Sig
From: Pekka Paalanen
Implement a way to do composition clipping with a region32 given in
source image space.
Pixman does not directly support this kind of operation at all. If you
pixman_image_set_clip_region32() on a source image, it will be ignored
unless you also
pixman_image_set_sour
From: Pekka Paalanen
Move code into a new helper function. No changes.
Signed-off-by: Pekka Paalanen
Reviewed-By: Derek Foreman
---
src/pixman-renderer.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/src/pixman-renderer.c b/src/pixman-re
From: Pekka Paalanen
This will be used by pixman-renderer.
v2: Fix doc typo.
Signed-off-by: Pekka Paalanen
Reviewed-By: Derek Foreman
---
src/compositor.c | 36
src/compositor.h | 5 +
2 files changed, 41 insertions(+)
diff --git a/src/compositor.c
From: Jason Ekstrand
Add matrix representations of these two transformations. Future patches
will leverage these to simplify the coordinate transformation code.
[Pekka: commit message]
Reviewed-by: Pekka Paalanen
---
src/compositor.c | 84 +++
From: Jason Ekstrand
Now that we have a buffer-to-surface matrix and the global-to-output matrix
is in pixels, we can remove a large chunk of confusing code from the pixman
renderer. Hopefully, having this stuff in weston core will keep the pixman
renderer from gettin broken quite as often.
Thi
From: Pekka Paalanen
Hi,
as requested by Derek, here is a revised series from
http://lists.freedesktop.org/archives/wayland-devel/2015-March/020440.html
The major addition to the series is that I pulled selected patches from
http://lists.freedesktop.org/archives/wayland-devel/2014-October/01780
From: Pekka Paalanen
Move the code computing the end-to-end transformation from
repaint_region() into a new function
pixman_renderer_compute_transform().
The code itself is not modified.
Signed-off-by: Pekka Paalanen
---
src/pixman-renderer.c | 41 +
1
From: Pekka Paalanen
The patch "zoom: Use pixels instead of GL coordinates" changed the
meaning of weston_output_zoom::trans_x,trans_y from GL coordinate system
to global coordinates.
This patch is a minimal untested change to the rpi-renderer to try and
follow up on that change.
Signed-off-by:
On Mon, 9 Mar 2015 23:57:36 -0700
"Jasper St. Pierre" wrote:
> The X11 xwm also draws decorations for client windows inside the compositor.
Yes it does, but that drawing is done for X11 (xcb) - I mean, that
Cairo drawing goes to a X11 Window directly, which then comes back from
Xwayland server f
30 matches
Mail list logo
