Re: [PATCH 0/6] RDP compositor needs love v2
Hi David, On Fri, May 27, 2016 at 6:48 AM, Hardening <rdp.eff...@gmail.com> wrote: > Le 26/04/2016 23:34, David Fort a écrit : >> Compared to the first version: >> compositor: recompute output position on mode switch >> desktop-shell: resize background, panel and lock surface on output >> resize >> I checked my mails and it seems like these two have been reviewed with comments by Pekka. -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] wayland-shm: Include wayland-util.h
On Sat, May 21, 2016 at 12:18 PM, Yong Bakos <j...@humanoriented.com> wrote: > From: Yong Bakos <yba...@humanoriented.com> > > wayland-shm.c uses WL_EXPORT and wl_array, which are defined in > wayland-util.h. > > Include wayland-util.h explicitly, rather than transitively through > wayland-server.h. > > Signed-off-by: Yong Bakos <yba...@humanoriented.com> > --- > src/wayland-shm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/wayland-shm.c b/src/wayland-shm.c > index 5efbd70..20bb8c8 100644 > --- a/src/wayland-shm.c > +++ b/src/wayland-shm.c > @@ -40,6 +40,7 @@ > #include > #include > > +#include "wayland-util.h" > #include "wayland-private.h" > #include "wayland-server.h" > > -- > 2.7.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel Technically makes sense to me, always better to have a flat include tree than one where the dependencies are hidden. Reviewed-by: Sam Spilsbury <smspil...@gmail.com> ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] event-loop: Include wayland-util.h
On Sat, May 21, 2016 at 12:23 PM, Yong Bakos <j...@humanoriented.com> wrote: > From: Yong Bakos <yba...@humanoriented.com> > > event-loop.c uses WL_EXPORT and wl_list, which are defined in > wayland-util.h. > > Include wayland-util.h explicitly, rather than transitively through > wayland-server-core.h. > > Signed-off-by: Yong Bakos <yba...@humanoriented.com> > --- > src/event-loop.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/event-loop.c b/src/event-loop.c > index 11a9bf2..7f1c7e5 100644 > --- a/src/event-loop.c > +++ b/src/event-loop.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include "wayland-util.h" > #include "wayland-private.h" > #include "wayland-server-core.h" > #include "wayland-os.h" > -- > 2.7.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel Technically makes sense to me, always better to have a flat include tree than one where the dependencies are hidden. Reviewed-by: Sam Spilsbury <smspil...@gmail.com> ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] rdp: don't release the seat until it is safe v2
On Fri, May 20, 2016 at 5:33 PM, David Fort <rdp.eff...@gmail.com> wrote:
> Releasing a seat is not safe, so let's just announce it without keyboard
> and mouse until this is fixed. Without this patch we just can't reconnect on
> the RDP compositor as it crashes.
>
> v2: fixed the leak of the xkb_keymap
>
> Signed-off-by: David Fort <cont...@hardening-consulting.com>
> ---
> src/compositor-rdp.c | 33 -
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 4fc7c74..52cf426 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -109,7 +109,7 @@ enum peer_item_flags {
> struct rdp_peers_item {
> int flags;
> freerdp_peer *peer;
> - struct weston_seat seat;
> + struct weston_seat *seat;
>
> struct wl_list link;
> };
> @@ -640,9 +640,9 @@ rdp_peer_context_free(freerdp_peer* client,
> RdpPeerContext* context)
> }
>
> if (context->item.flags & RDP_PEER_ACTIVATED) {
> - weston_seat_release_keyboard(>item.seat);
> - weston_seat_release_pointer(>item.seat);
> - weston_seat_release(>item.seat);
> + weston_seat_release_keyboard(context->item.seat);
> + weston_seat_release_pointer(context->item.seat);
> + /*weston_seat_release(context->item.seat);*/
> }
I think instead of just having commented out code, put the reasons why
the seat cannot be released safely at the moment. Just having it
commented out will confuse future maintainers.
>
> Stream_Free(context->encode_stream, TRUE);
> @@ -911,9 +911,16 @@ xf_peer_activate(freerdp_peer* client)
> else
> snprintf(seat_name, sizeof(seat_name), "RDP peer @%s",
> settings->ClientAddress);
>
> - weston_seat_init(>seat, b->compositor, seat_name);
> - weston_seat_init_keyboard(>seat, keymap);
> - weston_seat_init_pointer(>seat);
> + peersItem->seat = zalloc(sizeof(*peersItem->seat));
> + if (!peersItem->seat) {
> + xkb_keymap_unref(keymap);
> + weston_log("unable to create a weston_seat\n");
> + return FALSE;
> + }
> +
> + weston_seat_init(peersItem->seat, b->compositor, seat_name);
> + weston_seat_init_keyboard(peersItem->seat, keymap);
> + weston_seat_init_pointer(peersItem->seat);
Any reason to make this dynamically allocated memory? It seems to me
like it is adding an additional point of failure for little added
benefit. If it needs to be dynamically allocated, I think such a
change should come in a separate patch, since it seems unrelated to
this one.
Reviewed-by: Sam Spilsbury <smspil...@gmail.com>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Unit testing a wayland client
On Fri, Apr 1, 2016 at 9:30 PM, Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Fri, 1 Apr 2016 12:57:18 + > "Wagner, Michael" <michael_wag...@mentor.com> wrote: > > > Hi, > > > > I am currently looking into possibilities for unit testing our > > client whether it calls wayland functions in the correct > > form (order, content, etc.) > > > > So I wanted to use fake wl_* functions for mocking > > purposes. This seems to be not possible as all the > > wayland-scanner generated protocol functions carry > > the function definition already in the header file. > > This leads to compiler errors (multiple definition). > > > > My question would be, what is the reasoning behind > > putting all definitions already in the header? > > This way we do not need to distribute a shim library along with every > protocol extension. See all the extensions in the wayland-protocols > repository. > > > Maybe I'm completely looking into the wrong direction, > > and you have any suggestions on how to unit test a > > client application, any hints would be appreciated. > > How about mocking libwayland-client ABI (wayland-client-core.h) instead > of the generated protocol API? > > Or, maybe use the real deal and mock up a server instead? Though maybe > that's not unit-testing anymore. For a precedent, I did something similar for Kodi some time ago[0]. Its not really a mock of the server, as much as it is a protocol and extension for the tests to interact with the client. [0] https://github.com/MaxKellermann/xbmc/blob/master/xbmc/windowing/tests/wayland/XBMCWaylandTestExtension.cpp (Sadly, it looks like wayland support was dropped from Kodi due to my (admitted) failure to maintain it. But I'm glad others are looking into getting it back into shape). > > You could also look for inspiration in the Wayland test suite, even > though it is quite ad hoc. > > > Thanks, > pq > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Vertex clipping and primitive types
On 20/09/2013 5:09 AM, Bill Spitzak spit...@gmail.com wrote: Sam Spilsbury wrote: The point is to any arbitrary geometry against a rectangle. This is used to ensure that redraw areas only stick to damage areas. I suspect the most efficient thing to do is to clip against the bounding box of the obscuring object, even if that produces excess redraw, due to the complexity of arbitrary clip exceeding the time saved from the smaller redraw. It may be useful to do an accurate test for no-intersection, and if they intersect produce a 4-sided intersection of both bounding boxes. Also watch out for antialiased edges, the mathematically correct intersection test may give a false negative. Hi Bill. I don't known if occlusion optimization is done yet, but we already clip geometry against damage boxes (see the texture_region dance). Occlusion detection is somewhat orthogonal to what in talking about here. What I've been talking about here is that this clipping doesn't support arbitrary nonlinear transforms (eg vertex mesh), and then there is the additional problem of where primitive types need to be specified. In any case, pq and I worked out a semi-suitable design for this yesterday. The shell provides a function to the renderer used to generate multiple arrays of source transformation points (think texcoords) and then provides a function to Weston core (also available to the renderer) to transform a source point to a destination point (which it can do however it likes). Core used this second function to calculate the final clip box, as damage is submitted to Weston in buffer-space and also to do input transformation. The renderer uses it to get the destination mesh from then source mesh. The primitive types in that instance become an implementation detail on the renderer side, so we can pick whatever is best and clip it to the damage boxes properly. In any event, I think a first implementation is probably a better test of how well this works than lots of discussion. Sam. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Vertex clipping and primitive types
Hey all, I've started playing around with trying to get weston surfaces (or views as they will later be called) to use arbitrary vertex meshes. This would allow for more complex geometry and effects with the demo compositor. Currently, the vertex clipping implementation supports up to eight vertices and assumes that they are arranged in a fan (eg GL_TRIANGLE_FAN)[1]. I'm pretty sure that most geometry can be covered as long as we support GL_TRIANGLES (disjunct triangles), GL_TRIANGLE_STRIP (quadrilaterals or other sequential meshes) and GL_TRIANGLE_FAN (circles). The latter two of these essentially work by inferring a path between previous vertices and the next vertex in a sequence after n 2. For instance: GL_TRIANGLE: Line explicit between n and n - 1. GL_TRIANGLE_STRIP: Line explicit between n and n - 1 and inferred between n and n - 2. GL_TRIANGLE_FAN: Line explicit between n and n - 1 and inferred between n and 1. Currently, our clipping code doesn't take these inferred paths into account (it only clips the explicit between n and n - 1). Which means that geometry arranged as a strip of sequential rectangles gets clipped along the diagonal between the concentric triangles. The more or less obvious solution is to do this: GL_TRIANGLE_STRIP: Clip explicit path and clip implicit path from n to n - 2. GL_TRIANGLE_FAN: Clip explicit path and clip implicit path from n to 1. However, it gets a little more complicated than this, because a quadrilateral can have its vertices arranged in such a way that it would pass as both a GL_TRIANGLE_STRIP and GL_TRIANGLE_FAN. That is, if the vertices are arranged such that they wind in a particular direction, eg: x1,y1 - x2,y1 - x2,y2 - x1,y2 (counterclockwise) or x1,y1 - x1,y2 - x2,y2 - x2,y1 (clockwise) In that case, even though the mesh would still be a valid GL_TRIANGLE_STRIP, we can't clip the n - 2 path because for the fourth vertex, a path is inferred between 4 and 1 and not 4 and 2. I've been trying to think of ways to solve this problem: In both solutions we will need the vertex mesh to specify its primitive type (for obvious reasons). The first solution is to detect such winding and infer the path as though the mesh was a fan. I think this this problem is only going to be relevant to GL_TRIANGLE_STRIP arrangements that could also be expressed as a GL_TRIANGLE_FAN without any ordering adjustments. The second solution would be to require that a GL_TRIANGLE_STRIP is arranged in such a way that it cannot also be a GL_TRIANGLE_FAN without any ordering change. That way, we can assume that clipping the n - 2 path for a STRIP will always be correct. Thoughts? Sam. [1] For those who are curious about the various primitive types, have a look at http://www.opengl.org/wiki/Primitive -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Vertex clipping and primitive types
Hi Bill, On Sep 19, 2013 11:49 AM, Bill Spitzak spit...@gmail.com wrote: Sam Spilsbury wrote: Hey all, I've started playing around with trying to get weston surfaces (or views as they will later be called) to use arbitrary vertex meshes. Do you have an explanation for views? I thought wayland already supported putting the same buffer in more than one surface, so I don't see the purpose of views. Views as in Jason Ekstrand's proposal. Its more or less orthogonal to this (but just a clarification as to where things live in the stack). This proposal is for warping windows, not for just making non-rectangular shapes, right? I think non-rectangular shapes are intended to be done by using transparent pixels in the buffer. Correct - although this is done on the compositor side and not by clients. It is used to implement more complex animations like wobbly windows. Currently, the vertex clipping implementation supports up to eight vertices and assumes that they are arranged in a fan (eg GL_TRIANGLE_FAN)[1]. I'm pretty sure that most geometry can be covered as long as we support GL_TRIANGLES (disjunct triangles), GL_TRIANGLE_STRIP (quadrilaterals or other sequential meshes) and GL_TRIANGLE_FAN (circles). You don't intend to clip arbitrary shapes against each other, right? You just want to go in after the clipping has produced these 8 triangles. The point is to any arbitrary geometry against a rectangle. This is used to ensure that redraw areas only stick to damage areas. Sam. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 4/4] Added tests for the vertex clipping code.
Thanks. We should probably have a discussion at some point as to the best guidelines on how to split the code up for unit testing purposes. For now I'll move ahead with getting the vertex clipping code to support N vertices while still passing these tests. I probably won't be able to start that for a few weeks though. Sam. On 17/09/2013 12:41 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: On Fri, Sep 13, 2013 at 10:01:22AM +0800, Sam Spilsbury wrote: This tests (via the table-driven testing method) that the correct number of vertices and also the correct vertices themselves are generated for an clip box and polygon of up to eight vertices. Also add a libshared-test.la so that we don't have to build weston-test-runner all the time Hi Sam, I've committed these two, let's not get stuck on how to split it. Kristian --- tests/Makefile.am| 37 +--- tests/vertex-clip-test.c | 219 +++ 2 files changed, 245 insertions(+), 11 deletions(-) create mode 100644 tests/vertex-clip-test.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 3a36619..5be52c6 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,7 +1,8 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests) shared_tests = \ - config-parser.test + config-parser.test \ + vertex-clip.test module_tests = \ surface-test.la \ @@ -48,13 +49,6 @@ AM_CPPFLAGS = \ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) - -config_parser_test_LDADD = \ - ../shared/libshared.la \ - $(COMPOSITOR_LIBS) -config_parser_test_SOURCES = \ - config-parser-test.c - surface_global_test_la_SOURCES = surface-global-test.c surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c @@ -72,17 +66,38 @@ weston_test_la_SOURCES = \ weston_test_runner_src = \ weston-test-runner.c\ weston-test-runner.h + +check_LTLIBRARIES = libshared-test.la + +libshared_test_la_SOURCES = \ + $(weston_test_runner_src) +libshared_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) + +config_parser_test_LDADD = \ + ../shared/libshared.la \ + libshared-test.la \ + $(COMPOSITOR_LIBS) +config_parser_test_SOURCES = \ + config-parser-test.c +vertex_clip_test_SOURCES = \ + vertex-clip-test.c \ + ../src/vertex-clipping.c\ + ../src/vertex-clipping.h +vertex_clip_test_LDADD = \ + libshared-test.la \ + -lm -lrt + weston_test_client_src = \ weston-test-client-helper.c \ weston-test-client-helper.h \ wayland-test-protocol.c \ wayland-test-client-protocol.h \ subsurface-protocol.c \ - subsurface-client-protocol.h\ - $(weston_test_runner_src) + subsurface-client-protocol.h weston_test_client_libs =\ $(SIMPLE_CLIENT_LIBS) \ - ../shared/libshared.la + ../shared/libshared.la \ + libshared-test.la keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src) keyboard_weston_LDADD = $(weston_test_client_libs) diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c new file mode 100644 index 000..5b2e08c --- /dev/null +++ b/tests/vertex-clip-test.c @@ -0,0 +1,219 @@ +/* + * Copyright © 2013 Sam Spilsbury smspil...@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. + */ +#include assert.h +#include stdio.h +#include
Re: [PATCH 3/4] Split vertex clipping code out into vertex-clipping.c
Hi Kristian,
On Sat, Sep 14, 2013 at 6:35 AM, Kristian Høgsberg hoegsb...@gmail.com wrote:
On Fri, Sep 13, 2013 at 10:01:21AM +0800, Sam Spilsbury wrote:
---
src/Makefile.am | 4 +-
src/gl-renderer.c | 292 +-
src/vertex-clipping.c | 317
++
src/vertex-clipping.h | 65 +++
4 files changed, 389 insertions(+), 289 deletions(-)
create mode 100644 src/vertex-clipping.c
create mode 100644 src/vertex-clipping.h
Wouldn't it be nicer to make calculate_edges() the entry point into
the clipping code? As it is, too many internal details spill into the
header and much of the clipping logic is still in calculate_edges().
The only problem I see is that calculate_edges() calls
weston_surface_to_global_float(), but we can stub that out.
I thought about this, but decided against it for two reasons:
1. There's that dependency on weston_surface_to_global_float. There
are many ways to stub it out, and neither of them are really
satisfactory:
a. You can pass weston_surface_to_global_float as a function pointer
to calculate_edges, which means that unless you pass
weston_surface_to_global_float, or something that does exactly the
same thing, tex-coord generation will be broken.
b. You can modify weston_surface_to_global float to take as
parameters the bits of weston_surface and weston_output that it only
depends on, but that means lots of changes to those functions, which
are not in the scope of this patch.
c. Link-seam stubbing, which is really hard to do properly and also
really fragile
2. calculate_edges has two responsibilities:
a. First to figure out the vertices by clipping against some
arbitrary rectangle and
b. Secondly to figure out texcoords by taking the projected vertices
and mapping them on to the texture, rotating and scaling as necessary
and then normalizing from 0-1.
Those responsibilities are more or less independent of each other and
as such they should be tested as independent units.
I don't think that exposing clip_simple and clip_transformed exposes
too much implementation detail. They more-or-less operate on
free-standing data-sets and are utility functions to perform a
particular purpose. In fact, splitting them out from calculate_edges
makes it far clearer what calculate_edges responsibilities are, since
it operates at one level of abstraction higher.
Best Regards,
Sam.
Kristian
diff --git a/src/Makefile.am b/src/Makefile.am
index 3710be6..92426b0 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -52,7 +52,9 @@ weston_SOURCES =\
if ENABLE_EGL
weston_SOURCES +=\
- gl-renderer.c
+ gl-renderer.c \
+ vertex-clipping.c \
+ vertex-clipping.h
endif
git-version.h : .FORCE
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 4381a2e..6999121 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -33,6 +33,7 @@
#include linux/input.h
#include gl-renderer.h
+#include vertex-clipping.h
#include EGL/eglext.h
#include weston-egl-ext.h
@@ -179,270 +180,8 @@ gl_renderer_print_egl_error_state(void)
egl_error_string(code), (long)code);
}
-struct polygon8 {
- GLfloat x[8];
- GLfloat y[8];
- int n;
-};
-
-struct clip_context {
- struct {
- GLfloat x;
- GLfloat y;
- } prev;
-
- struct {
- GLfloat x1, y1;
- GLfloat x2, y2;
- } clip;
-
- struct {
- GLfloat *x;
- GLfloat *y;
- } vertices;
-};
-
-static GLfloat
-float_difference(GLfloat a, GLfloat b)
-{
- /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
- static const GLfloat max_diff = 4.0f * FLT_MIN;
- static const GLfloat max_rel_diff = 4.0e-5;
- GLfloat diff = a - b;
- GLfloat adiff = fabsf(diff);
-
- if (adiff = max_diff)
- return 0.0f;
-
- a = fabsf(a);
- b = fabsf(b);
- if (adiff = (a b ? a : b) * max_rel_diff)
- return 0.0f;
-
- return diff;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
- * Compute the y coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
- GLfloat x_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1x, p2x);
-
- /* Practically vertical line segment, yet the end points have already
- * been determined to be on different sides of the line. Therefore
- * the line segment is part of the line and intersects everywhere.
- * Return the end point, so we use the whole line segment.
- */
- if (diff == 0.0f)
- return p2y;
-
- a = (x_arg - p2x) / diff;
- return p2y + (p1y - p2y
[PATCH 0/4] Table driven tests for the vertex clipping code
This is the third series of patches for adding table driven tests for the vertex clipping code. From the last series I fixed some a stray use of .a when it should have been .la and also rebased on some recent work that happened in git master. Sam Spilsbury (4): Remove AM_LDFLAGS usage Add support for table-driven testing. Split vertex clipping code out into vertex-clipping.c in shared/ Added tests for the vertex clipping code. shared/Makefile.am | 4 +- shared/vertex-clipping.c | 317 + shared/vertex-clipping.h | 65 ++ src/gl-renderer.c | 292 + tests/Makefile.am | 42 -- tests/vertex-clip-test.c | 219 +++ tests/weston-test-runner.c | 123 +++--- tests/weston-test-runner.h | 52 +--- 8 files changed, 751 insertions(+), 363 deletions(-) create mode 100644 shared/vertex-clipping.c create mode 100644 shared/vertex-clipping.h create mode 100644 tests/vertex-clip-test.c -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/4] Remove AM_LDFLAGS usage
We are not building everything here as a module, only the test modules. --- tests/Makefile.am | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 398a275..3a36619 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -7,6 +7,8 @@ module_tests = \ surface-test.la \ surface-global-test.la +weston_test = weston-test.la + weston_tests = \ keyboard.weston \ event.weston\ @@ -45,7 +47,7 @@ AM_CPPFLAGS = \ -I$(top_builddir)/src \ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) -AM_LDFLAGS = -module -avoid-version -rpath $(libdir) + config_parser_test_LDADD = \ ../shared/libshared.la \ @@ -54,11 +56,13 @@ config_parser_test_SOURCES =\ config-parser-test.c surface_global_test_la_SOURCES = surface-global-test.c +surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c +surface_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) -weston_test = weston-test.la weston_test_la_LIBADD = $(COMPOSITOR_LIBS) \ ../shared/libshared.la +weston_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) weston_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) weston_test_la_SOURCES = \ weston-test.c \ -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/4] Add support for table-driven testing.
= !success;
-
- if (success !hardfail) {
- pass++;
- fprintf(stderr, , pass.\n);
- } else
- fprintf(stderr, , fail.\n);
}
- total = __stop_test_section - __start_test_section;
fprintf(stderr, %d tests, %d pass, %d fail\n,
total, pass, total - pass);
diff --git a/tests/weston-test-runner.h b/tests/weston-test-runner.h
index 41df386..457cf31 100644
--- a/tests/weston-test-runner.h
+++ b/tests/weston-test-runner.h
@@ -1,5 +1,6 @@
/*
* Copyright © 2012 Intel Corporation
+ * Copyright © 2013 Sam Spilsbury smspil...@gmail.com
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
@@ -23,34 +24,53 @@
#ifndef _WESTON_TEST_RUNNER_H_
#define _WESTON_TEST_RUNNER_H_
+#include stdlib.h
+
#ifdef NDEBUG
#error Tests must not be built with NDEBUG defined, they rely on assert().
#endif
struct weston_test {
const char *name;
- void (*run)(void);
+ void (*run)(void *);
+ const void *table_data;
+ size_t element_size;
+ int n_elements;
int must_fail;
-} __attribute__ ((aligned (16)));
+} __attribute__ ((aligned (32)));
-#define TEST(name) \
- static void name(void); \
+#define TEST_BEGIN(name, arg) \
+ static void name(arg)
+
+#define TEST_COMMON(func, name, ret, data, size, n_elem) \
+ static void func(void *); \
\
const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 0 \
- }; \
- \
- static void name(void)
+ __attribute__ ((section (test_section))) =\
+ { \
+ #name, func, data, size, n_elem, ret\
+ };
-#define FAIL_TEST(name)\
+#define NO_ARG_TEST(name, ret) \
+ TEST_COMMON(wrap##name, name, ret, NULL, 0, 1) \
static void name(void); \
+ static void wrap##name(void *data) \
+ { \
+ (void) data;\
+ name(); \
+ } \
\
- const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 1 \
- }; \
- \
- static void name(void)
+ TEST_BEGIN(name, void)
+
+#define ARG_TEST(name, ret, test_data) \
+ TEST_COMMON(name, name, ret, test_data, \
+ sizeof(test_data[0]), \
+ sizeof(test_data) / sizeof (test_data[0])) \
+ TEST_BEGIN(name, void *data)\
+
+#define TEST(name) NO_ARG_TEST(name, 0)
+#define FAIL_TEST(name) NO_ARG_TEST(name, 1)
+#define TEST_P(name, data) ARG_TEST(name, 0, data)
+#define FAIL_TEST_P(name, data) ARG_TEST(name, 1, data)
#endif
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/4] Split vertex clipping code out into vertex-clipping.c in shared/
---
shared/Makefile.am | 4 +-
shared/vertex-clipping.c | 317 +++
shared/vertex-clipping.h | 65 ++
src/gl-renderer.c| 292 +--
4 files changed, 389 insertions(+), 289 deletions(-)
create mode 100644 shared/vertex-clipping.c
create mode 100644 shared/vertex-clipping.h
diff --git a/shared/Makefile.am b/shared/Makefile.am
index 2fcff7b..f1abc61 100644
--- a/shared/Makefile.am
+++ b/shared/Makefile.am
@@ -7,7 +7,9 @@ libshared_la_SOURCES = \
option-parser.c \
config-parser.h \
os-compatibility.c \
- os-compatibility.h
+ os-compatibility.h \
+ vertex-clipping.c \
+ vertex-clipping.h
libshared_cairo_la_CFLAGS =\
$(GCC_CFLAGS) \
diff --git a/shared/vertex-clipping.c b/shared/vertex-clipping.c
new file mode 100644
index 000..603ce6f
--- /dev/null
+++ b/shared/vertex-clipping.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ *
+ * 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.
+ */
+#include assert.h
+#include float.h
+#include math.h
+
+#include GLES2/gl2.h
+
+#include vertex-clipping.h
+
+GLfloat
+float_difference(GLfloat a, GLfloat b)
+{
+ /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
+ static const GLfloat max_diff = 4.0f * FLT_MIN;
+ static const GLfloat max_rel_diff = 4.0e-5;
+ GLfloat diff = a - b;
+ GLfloat adiff = fabsf(diff);
+
+ if (adiff = max_diff)
+ return 0.0f;
+
+ a = fabsf(a);
+ b = fabsf(b);
+ if (adiff = (a b ? a : b) * max_rel_diff)
+ return 0.0f;
+
+ return diff;
+}
+
+/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
+ * Compute the y coordinate of the intersection.
+ */
+static GLfloat
+clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
+GLfloat x_arg)
+{
+ GLfloat a;
+ GLfloat diff = float_difference(p1x, p2x);
+
+ /* Practically vertical line segment, yet the end points have already
+* been determined to be on different sides of the line. Therefore
+* the line segment is part of the line and intersects everywhere.
+* Return the end point, so we use the whole line segment.
+*/
+ if (diff == 0.0f)
+ return p2y;
+
+ a = (x_arg - p2x) / diff;
+ return p2y + (p1y - p2y) * a;
+}
+
+/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line y = y_arg.
+ * Compute the x coordinate of the intersection.
+ */
+static GLfloat
+clip_intersect_x(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
+GLfloat y_arg)
+{
+ GLfloat a;
+ GLfloat diff = float_difference(p1y, p2y);
+
+ /* Practically horizontal line segment, yet the end points have already
+* been determined to be on different sides of the line. Therefore
+* the line segment is part of the line and intersects everywhere.
+* Return the end point, so we use the whole line segment.
+*/
+ if (diff == 0.0f)
+ return p2x;
+
+ a = (y_arg - p2y) / diff;
+ return p2x + (p1x - p2x) * a;
+}
+
+enum path_transition {
+ PATH_TRANSITION_OUT_TO_OUT = 0,
+ PATH_TRANSITION_OUT_TO_IN = 1,
+ PATH_TRANSITION_IN_TO_OUT = 2,
+ PATH_TRANSITION_IN_TO_IN = 3,
+};
+
+static void
+clip_append_vertex(struct clip_context *ctx, GLfloat x, GLfloat y)
+{
+ *ctx-vertices.x++ = x;
+ *ctx-vertices.y++ = y;
+}
+
+static enum path_transition
+path_transition_left_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
+{
+
[PATCH 4/4] Added tests for the vertex clipping code.
This tests (via the table-driven testing method) that the correct
number of vertices and also the correct vertices themselves
are generated for an clip box and polygon of up to eight vertices.
Also add a libshared_test.a so that we don't have to build weston-test-runner
all the time
---
tests/Makefile.am| 36 +---
tests/vertex-clip-test.c | 219 +++
2 files changed, 244 insertions(+), 11 deletions(-)
create mode 100644 tests/vertex-clip-test.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 3a36619..d2d2d8a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,7 +1,8 @@
TESTS = $(shared_tests) $(module_tests) $(weston_tests)
shared_tests = \
- config-parser.test
+ config-parser.test \
+ vertex-clip.test
module_tests = \
surface-test.la \
@@ -48,13 +49,6 @@ AM_CPPFLAGS =\
-DUNIT_TEST \
$(COMPOSITOR_CFLAGS)
-
-config_parser_test_LDADD = \
- ../shared/libshared.la \
- $(COMPOSITOR_LIBS)
-config_parser_test_SOURCES = \
- config-parser-test.c
-
surface_global_test_la_SOURCES = surface-global-test.c
surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir)
surface_test_la_SOURCES = surface-test.c
@@ -72,17 +66,37 @@ weston_test_la_SOURCES =\
weston_test_runner_src = \
weston-test-runner.c\
weston-test-runner.h
+
+check_LTLIBRARIES = libshared_test.la
+
+libshared_test_la_SOURCES =\
+ $(weston_test_runner_src)
+libshared_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS)
+
+config_parser_test_LDADD = \
+ ../shared/libshared.la \
+ libshared_test.la \
+ $(COMPOSITOR_LIBS)
+config_parser_test_SOURCES = \
+ config-parser-test.c
+vertex_clip_test_SOURCES = \
+ vertex-clip-test.c
+vertex_clip_test_LDADD = \
+ ../shared/libshared.la \
+ libshared_test.la \
+ -lm -lrt
+
weston_test_client_src = \
weston-test-client-helper.c \
weston-test-client-helper.h \
wayland-test-protocol.c \
wayland-test-client-protocol.h \
subsurface-protocol.c \
- subsurface-client-protocol.h\
- $(weston_test_runner_src)
+ subsurface-client-protocol.h
weston_test_client_libs = \
$(SIMPLE_CLIENT_LIBS) \
- ../shared/libshared.la
+ ../shared/libshared.la \
+ libshared_test.la
keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src)
keyboard_weston_LDADD = $(weston_test_client_libs)
diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c
new file mode 100644
index 000..51188b2
--- /dev/null
+++ b/tests/vertex-clip-test.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright © 2013 Sam Spilsbury smspil...@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.
+ */
+#include assert.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include math.h
+
+#include weston-test-runner.h
+
+#include ../shared/vertex-clipping.h
+
+#define BOUNDING_BOX_TOP_Y 100.0f
+#define BOUNDING_BOX_LEFT_X 50.0f
+#define BOUNDING_BOX_RIGHT_X 100.0f
+#define BOUNDING_BOX_BOTTOM_Y 50.0f
+
+#define INSIDE_X1 (BOUNDING_BOX_LEFT_X + 1.0f)
+#define INSIDE_X2 (BOUNDING_BOX_RIGHT_X - 1.0f)
+#define INSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y + 1.0f)
+#define INSIDE_Y2 (BOUNDING_BOX_TOP_Y - 1.0f)
+
+#define OUTSIDE_X1 (BOUNDING_BOX_LEFT_X - 1.0f)
+#define OUTSIDE_X2 (BOUNDING_BOX_RIGHT_X + 1.0f)
+#define OUTSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y - 1.0f)
+#define OUTSIDE_Y2 (BOUNDING_BOX_TOP_Y + 1.0f)
+
+static void
+populate_clip_context (struct clip_context *ctx)
+{
+ ctx-clip.x1
[PATCH 0/4] Table driven tests for the vertex clipping code
This is the fourth series of patches for adding table driven tests for the vertex clipping code. From the last series I moved vertex-clipping into src/ and built each object twice. Its not my preferred way of doing it, but we should probably figure out how we're going to have the code split into libraries for testing purposes later. Also renamed libshared_test to libshared-test Sam Spilsbury (4): Remove AM_LDFLAGS usage Add support for table-driven testing. Split vertex clipping code out into vertex-clipping.c Added tests for the vertex clipping code. src/Makefile.am| 4 +- src/gl-renderer.c | 292 + src/vertex-clipping.c | 317 + src/vertex-clipping.h | 65 ++ tests/Makefile.am | 43 -- tests/vertex-clip-test.c | 219 +++ tests/weston-test-runner.c | 123 +++--- tests/weston-test-runner.h | 52 +--- 8 files changed, 752 insertions(+), 363 deletions(-) create mode 100644 src/vertex-clipping.c create mode 100644 src/vertex-clipping.h create mode 100644 tests/vertex-clip-test.c -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/4] Remove AM_LDFLAGS usage
We are not building everything here as a module, only the test modules. --- tests/Makefile.am | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 398a275..3a36619 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -7,6 +7,8 @@ module_tests = \ surface-test.la \ surface-global-test.la +weston_test = weston-test.la + weston_tests = \ keyboard.weston \ event.weston\ @@ -45,7 +47,7 @@ AM_CPPFLAGS = \ -I$(top_builddir)/src \ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) -AM_LDFLAGS = -module -avoid-version -rpath $(libdir) + config_parser_test_LDADD = \ ../shared/libshared.la \ @@ -54,11 +56,13 @@ config_parser_test_SOURCES =\ config-parser-test.c surface_global_test_la_SOURCES = surface-global-test.c +surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c +surface_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) -weston_test = weston-test.la weston_test_la_LIBADD = $(COMPOSITOR_LIBS) \ ../shared/libshared.la +weston_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) weston_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) weston_test_la_SOURCES = \ weston-test.c \ -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/4] Add support for table-driven testing.
= !success;
-
- if (success !hardfail) {
- pass++;
- fprintf(stderr, , pass.\n);
- } else
- fprintf(stderr, , fail.\n);
}
- total = __stop_test_section - __start_test_section;
fprintf(stderr, %d tests, %d pass, %d fail\n,
total, pass, total - pass);
diff --git a/tests/weston-test-runner.h b/tests/weston-test-runner.h
index 41df386..457cf31 100644
--- a/tests/weston-test-runner.h
+++ b/tests/weston-test-runner.h
@@ -1,5 +1,6 @@
/*
* Copyright © 2012 Intel Corporation
+ * Copyright © 2013 Sam Spilsbury smspil...@gmail.com
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
@@ -23,34 +24,53 @@
#ifndef _WESTON_TEST_RUNNER_H_
#define _WESTON_TEST_RUNNER_H_
+#include stdlib.h
+
#ifdef NDEBUG
#error Tests must not be built with NDEBUG defined, they rely on assert().
#endif
struct weston_test {
const char *name;
- void (*run)(void);
+ void (*run)(void *);
+ const void *table_data;
+ size_t element_size;
+ int n_elements;
int must_fail;
-} __attribute__ ((aligned (16)));
+} __attribute__ ((aligned (32)));
-#define TEST(name) \
- static void name(void); \
+#define TEST_BEGIN(name, arg) \
+ static void name(arg)
+
+#define TEST_COMMON(func, name, ret, data, size, n_elem) \
+ static void func(void *); \
\
const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 0 \
- }; \
- \
- static void name(void)
+ __attribute__ ((section (test_section))) =\
+ { \
+ #name, func, data, size, n_elem, ret\
+ };
-#define FAIL_TEST(name)\
+#define NO_ARG_TEST(name, ret) \
+ TEST_COMMON(wrap##name, name, ret, NULL, 0, 1) \
static void name(void); \
+ static void wrap##name(void *data) \
+ { \
+ (void) data;\
+ name(); \
+ } \
\
- const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 1 \
- }; \
- \
- static void name(void)
+ TEST_BEGIN(name, void)
+
+#define ARG_TEST(name, ret, test_data) \
+ TEST_COMMON(name, name, ret, test_data, \
+ sizeof(test_data[0]), \
+ sizeof(test_data) / sizeof (test_data[0])) \
+ TEST_BEGIN(name, void *data)\
+
+#define TEST(name) NO_ARG_TEST(name, 0)
+#define FAIL_TEST(name) NO_ARG_TEST(name, 1)
+#define TEST_P(name, data) ARG_TEST(name, 0, data)
+#define FAIL_TEST_P(name, data) ARG_TEST(name, 1, data)
#endif
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/4] Split vertex clipping code out into vertex-clipping.c
---
src/Makefile.am | 4 +-
src/gl-renderer.c | 292 +-
src/vertex-clipping.c | 317 ++
src/vertex-clipping.h | 65 +++
4 files changed, 389 insertions(+), 289 deletions(-)
create mode 100644 src/vertex-clipping.c
create mode 100644 src/vertex-clipping.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 3710be6..92426b0 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -52,7 +52,9 @@ weston_SOURCES = \
if ENABLE_EGL
weston_SOURCES += \
- gl-renderer.c
+ gl-renderer.c \
+ vertex-clipping.c \
+ vertex-clipping.h
endif
git-version.h : .FORCE
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 4381a2e..6999121 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -33,6 +33,7 @@
#include linux/input.h
#include gl-renderer.h
+#include vertex-clipping.h
#include EGL/eglext.h
#include weston-egl-ext.h
@@ -179,270 +180,8 @@ gl_renderer_print_egl_error_state(void)
egl_error_string(code), (long)code);
}
-struct polygon8 {
- GLfloat x[8];
- GLfloat y[8];
- int n;
-};
-
-struct clip_context {
- struct {
- GLfloat x;
- GLfloat y;
- } prev;
-
- struct {
- GLfloat x1, y1;
- GLfloat x2, y2;
- } clip;
-
- struct {
- GLfloat *x;
- GLfloat *y;
- } vertices;
-};
-
-static GLfloat
-float_difference(GLfloat a, GLfloat b)
-{
- /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
- static const GLfloat max_diff = 4.0f * FLT_MIN;
- static const GLfloat max_rel_diff = 4.0e-5;
- GLfloat diff = a - b;
- GLfloat adiff = fabsf(diff);
-
- if (adiff = max_diff)
- return 0.0f;
-
- a = fabsf(a);
- b = fabsf(b);
- if (adiff = (a b ? a : b) * max_rel_diff)
- return 0.0f;
-
- return diff;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
- * Compute the y coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat x_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1x, p2x);
-
- /* Practically vertical line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2y;
-
- a = (x_arg - p2x) / diff;
- return p2y + (p1y - p2y) * a;
-}
-
-/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line y = y_arg.
- * Compute the x coordinate of the intersection.
- */
-static GLfloat
-clip_intersect_x(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
-GLfloat y_arg)
-{
- GLfloat a;
- GLfloat diff = float_difference(p1y, p2y);
-
- /* Practically horizontal line segment, yet the end points have already
-* been determined to be on different sides of the line. Therefore
-* the line segment is part of the line and intersects everywhere.
-* Return the end point, so we use the whole line segment.
-*/
- if (diff == 0.0f)
- return p2x;
-
- a = (y_arg - p2y) / diff;
- return p2x + (p1x - p2x) * a;
-}
-
-enum path_transition {
- PATH_TRANSITION_OUT_TO_OUT = 0,
- PATH_TRANSITION_OUT_TO_IN = 1,
- PATH_TRANSITION_IN_TO_OUT = 2,
- PATH_TRANSITION_IN_TO_IN = 3,
-};
-
-static void
-clip_append_vertex(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- *ctx-vertices.x++ = x;
- *ctx-vertices.y++ = y;
-}
-
-static enum path_transition
-path_transition_left_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.x = ctx-clip.x1) 1) | (x = ctx-clip.x1);
-}
-
-static enum path_transition
-path_transition_right_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.x ctx-clip.x2) 1) | (x ctx-clip.x2);
-}
-
-static enum path_transition
-path_transition_top_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.y = ctx-clip.y1) 1) | (y = ctx-clip.y1);
-}
-
-static enum path_transition
-path_transition_bottom_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
-{
- return ((ctx-prev.y ctx-clip.y2) 1) | (y ctx-clip.y2);
-}
-
-static void
-clip_polygon_leftright(struct clip_context *ctx,
- enum path_transition transition,
- GLfloat x, GLfloat y, GLfloat clip_x)
-{
- GLfloat yi;
-
- switch (transition) {
- case
[PATCH 4/4] Added tests for the vertex clipping code.
This tests (via the table-driven testing method) that the correct number of vertices and also the correct vertices themselves are generated for an clip box and polygon of up to eight vertices. Also add a libshared-test.la so that we don't have to build weston-test-runner all the time --- tests/Makefile.am| 37 +--- tests/vertex-clip-test.c | 219 +++ 2 files changed, 245 insertions(+), 11 deletions(-) create mode 100644 tests/vertex-clip-test.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 3a36619..5be52c6 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,7 +1,8 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests) shared_tests = \ - config-parser.test + config-parser.test \ + vertex-clip.test module_tests = \ surface-test.la \ @@ -48,13 +49,6 @@ AM_CPPFLAGS =\ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) - -config_parser_test_LDADD = \ - ../shared/libshared.la \ - $(COMPOSITOR_LIBS) -config_parser_test_SOURCES = \ - config-parser-test.c - surface_global_test_la_SOURCES = surface-global-test.c surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c @@ -72,17 +66,38 @@ weston_test_la_SOURCES =\ weston_test_runner_src = \ weston-test-runner.c\ weston-test-runner.h + +check_LTLIBRARIES = libshared-test.la + +libshared_test_la_SOURCES =\ + $(weston_test_runner_src) +libshared_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) + +config_parser_test_LDADD = \ + ../shared/libshared.la \ + libshared-test.la \ + $(COMPOSITOR_LIBS) +config_parser_test_SOURCES = \ + config-parser-test.c +vertex_clip_test_SOURCES = \ + vertex-clip-test.c \ + ../src/vertex-clipping.c\ + ../src/vertex-clipping.h +vertex_clip_test_LDADD = \ + libshared-test.la \ + -lm -lrt + weston_test_client_src = \ weston-test-client-helper.c \ weston-test-client-helper.h \ wayland-test-protocol.c \ wayland-test-client-protocol.h \ subsurface-protocol.c \ - subsurface-client-protocol.h\ - $(weston_test_runner_src) + subsurface-client-protocol.h weston_test_client_libs = \ $(SIMPLE_CLIENT_LIBS) \ - ../shared/libshared.la + ../shared/libshared.la \ + libshared-test.la keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src) keyboard_weston_LDADD = $(weston_test_client_libs) diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c new file mode 100644 index 000..5b2e08c --- /dev/null +++ b/tests/vertex-clip-test.c @@ -0,0 +1,219 @@ +/* + * Copyright © 2013 Sam Spilsbury smspil...@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. + */ +#include assert.h +#include stdio.h +#include stdlib.h +#include string.h +#include math.h + +#include weston-test-runner.h + +#include ../src/vertex-clipping.h + +#define BOUNDING_BOX_TOP_Y 100.0f +#define BOUNDING_BOX_LEFT_X 50.0f +#define BOUNDING_BOX_RIGHT_X 100.0f +#define BOUNDING_BOX_BOTTOM_Y 50.0f + +#define INSIDE_X1 (BOUNDING_BOX_LEFT_X + 1.0f) +#define INSIDE_X2 (BOUNDING_BOX_RIGHT_X - 1.0f) +#define INSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y + 1.0f) +#define INSIDE_Y2 (BOUNDING_BOX_TOP_Y - 1.0f) + +#define OUTSIDE_X1 (BOUNDING_BOX_LEFT_X - 1.0f) +#define OUTSIDE_X2 (BOUNDING_BOX_RIGHT_X + 1.0f) +#define OUTSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y - 1.0f) +#define OUTSIDE_Y2 (BOUNDING_BOX_TOP_Y + 1.0f) + +static void +populate_clip_context
Re: [PATCH weston 1/5] tests: always build tests
Quick thought: there's also an important psychological effect to building the tests on a standard make because it promotes them to the same importance as the rest of your code. They become less of an afterthought and it promotes greater care around how people design the tests (eg, making the tests clean, making sure they run quickly), as well as how the rest of the codebase interacts with the tests. We observed a similar effect at Canonical between the projects which had test building on by default as opposed to those that did not. It all depends on whether or not the tests are there as a basic safety line for managing releases or whether or not tests are used as a tool to iterate and improve quality. In the latter case, building them by default is a very sensible decision indeed. Regards, Sam. On Wed, Sep 11, 2013 at 4:53 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On 11/09/13 17:32 , sardemff7+wayl...@sardemff7.net wrote: On 11/09/2013 07:58, Peter Hutterer wrote: check_PROGRAMS and friends are only built during make check. Which is perfectly fine. Which is a great way of introducing compiler errors in tests. Agree, but we should fix the workflow, not some arbitrary “problem”. from my experience, every project I've worked on that has a test suite needed this patch eventually, there's always a way to forget to run make check and suddenly you find out that it's been broken for months. (this is largely because test suites have a tendency to become outdated and useless, but...) Always build them, TESTS defines what's being run during make check. That’s wrong. how so? TESTS defines what's run during make check. check_* defines what's built, the two are related but not the same. The check_* vars are meant this way to avoid forcing test-only dependencies if you disable tests and to allow one to test her code *before* updating the tests. Packagers tend to “fix” that the other way around (moving tests from noinst_ to check_) quite often… I know the principle, I'm claiming that without this, tests will eventually break unless you find a way to force everyone to run make check. Which, coincidentally, wastes maintainer time too if you get a patch that's fine but breaks make check and you have to get through another revision. Cheers, Peter --- tests/Makefile.am | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 82bf630..398a275 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -29,18 +29,14 @@ clean-local: export abs_builddir noinst_LTLIBRARIES =\ -$(weston_test) +$(weston_test)\ +$(module_tests) noinst_PROGRAMS =\ $(setbacklight)\ -matrix-test - -check_LTLIBRARIES =\ -$(module_tests) - -check_PROGRAMS =\ $(shared_tests)\ -$(weston_tests) +$(weston_tests)\ +matrix-test AM_CFLAGS = $(GCC_CFLAGS) AM_CPPFLAGS =\ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/5] tests: always build tests
On Wed, Sep 11, 2013 at 8:38 PM, sardemff7+wayl...@sardemff7.net wrote: On 11/09/2013 11:12, Sam Spilsbury wrote: Quick thought: there's also an important psychological effect to building the tests on a standard make because it promotes them to the same importance as the rest of your code. They become less of an afterthought and it promotes greater care around how people design the tests (eg, making the tests clean, making sure they run quickly), as well as how the rest of the codebase interacts with the tests. We observed a similar effect at Canonical between the projects which had test building on by default as opposed to those that did not. Then we should definitely fix users (developers) and their workflow, not some arbitrary “problem”, as I said already. I think we're all in agreement that having maintained tests is a good thing. Generally speaking I've found that most projects which use a test-driven workflow have them *built* by default and then have a separate rule (eg make check or make test) to run them. They also have a CI system which automatically runs the tests and fails patches which fail the tests. I don't know how well CI systems would work for a patches-on-the-mailinglist type workflow, but there are plenty of very well integrated systems for code hosts like launchpad and github. Building tests by default makes them more obvious, especially to newcomers. Running them by default would certainly make them even more obvious. But we don't run them by default because then we would have to accept the constant time process of running the tests every time make is invoked (which is about seven seconds in our case). There's also the problem with the weston tests not running headless (although they should). A run of the tests isn't mandatory every time the build completes - its up to the discretion of the developer as to when it would be appropriate to run them. Building them by default at least gives you quick feedback of when you stepped on a test. Building the tests by default is a structural change that promotes positive impacts on workflow and more thought about testing. It isn't an entire solution to the problem of developers not writing tests, but it certainly gets you part of the way there. At least with a testsuite which has no dependencies, there doesn't seem to be a very good reason not to at least build them by default. Best Regards, Sam. -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/4] Table driven tests for the vertex clipping code
This is the third series of patches for adding table driven tests for the vertex clipping code. From the last series I fixed some of the AM_LDFLAGS nightmare in tests/Makefile.am so that we don't have to build libshared_test into a static library and can instead use a libtool convenience library. Sam Spilsbury (4): Remove AM_LDFLAGS usage Add support for table-driven testing. Split vertex clipping code out into vertex-clipping.c in shared/ Added tests for the vertex clipping code. shared/Makefile.am | 4 +- shared/vertex-clipping.c | 317 + shared/vertex-clipping.h | 65 ++ src/gl-renderer.c | 292 + tests/Makefile.am | 40 -- tests/vertex-clip-test.c | 219 +++ tests/weston-test-runner.c | 123 +++--- tests/weston-test-runner.h | 52 +--- 8 files changed, 749 insertions(+), 363 deletions(-) create mode 100644 shared/vertex-clipping.c create mode 100644 shared/vertex-clipping.h create mode 100644 tests/vertex-clip-test.c -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/4] Remove AM_LDFLAGS usage
We are not building everything here as a module, only the test modules. --- tests/Makefile.am | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 82bf630..6234aa2 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -49,7 +49,7 @@ AM_CPPFLAGS = \ -I$(top_builddir)/src \ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) -AM_LDFLAGS = -module -avoid-version -rpath $(libdir) + config_parser_test_LDADD = \ ../shared/libshared.la \ @@ -58,11 +58,14 @@ config_parser_test_SOURCES =\ config-parser-test.c surface_global_test_la_SOURCES = surface-global-test.c +surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c +surface_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) weston_test = weston-test.la weston_test_la_LIBADD = $(COMPOSITOR_LIBS) \ ../shared/libshared.la +weston_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) weston_test_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) weston_test_la_SOURCES = \ weston-test.c \ -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/4] Add support for table-driven testing.
++;
- fprintf(stderr, , pass.\n);
- } else
- fprintf(stderr, , fail.\n);
}
- total = __stop_test_section - __start_test_section;
fprintf(stderr, %d tests, %d pass, %d fail\n,
total, pass, total - pass);
diff --git a/tests/weston-test-runner.h b/tests/weston-test-runner.h
index 41df386..457cf31 100644
--- a/tests/weston-test-runner.h
+++ b/tests/weston-test-runner.h
@@ -1,5 +1,6 @@
/*
* Copyright © 2012 Intel Corporation
+ * Copyright © 2013 Sam Spilsbury smspil...@gmail.com
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
@@ -23,34 +24,53 @@
#ifndef _WESTON_TEST_RUNNER_H_
#define _WESTON_TEST_RUNNER_H_
+#include stdlib.h
+
#ifdef NDEBUG
#error Tests must not be built with NDEBUG defined, they rely on assert().
#endif
struct weston_test {
const char *name;
- void (*run)(void);
+ void (*run)(void *);
+ const void *table_data;
+ size_t element_size;
+ int n_elements;
int must_fail;
-} __attribute__ ((aligned (16)));
+} __attribute__ ((aligned (32)));
-#define TEST(name) \
- static void name(void); \
+#define TEST_BEGIN(name, arg) \
+ static void name(arg)
+
+#define TEST_COMMON(func, name, ret, data, size, n_elem) \
+ static void func(void *); \
\
const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 0 \
- }; \
- \
- static void name(void)
+ __attribute__ ((section (test_section))) =\
+ { \
+ #name, func, data, size, n_elem, ret\
+ };
-#define FAIL_TEST(name)\
+#define NO_ARG_TEST(name, ret) \
+ TEST_COMMON(wrap##name, name, ret, NULL, 0, 1) \
static void name(void); \
+ static void wrap##name(void *data) \
+ { \
+ (void) data;\
+ name(); \
+ } \
\
- const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 1 \
- }; \
- \
- static void name(void)
+ TEST_BEGIN(name, void)
+
+#define ARG_TEST(name, ret, test_data) \
+ TEST_COMMON(name, name, ret, test_data, \
+ sizeof(test_data[0]), \
+ sizeof(test_data) / sizeof (test_data[0])) \
+ TEST_BEGIN(name, void *data)\
+
+#define TEST(name) NO_ARG_TEST(name, 0)
+#define FAIL_TEST(name) NO_ARG_TEST(name, 1)
+#define TEST_P(name, data) ARG_TEST(name, 0, data)
+#define FAIL_TEST_P(name, data) ARG_TEST(name, 1, data)
#endif
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 4/4] Added tests for the vertex clipping code.
This tests (via the table-driven testing method) that the correct number of vertices and also the correct vertices themselves are generated for an clip box and polygon of up to eight vertices. Also add a libshared_test.a so that we don't have to build weston-test-runner all the time --- tests/Makefile.am| 37 +--- tests/vertex-clip-test.c | 219 +++ 2 files changed, 244 insertions(+), 12 deletions(-) create mode 100644 tests/vertex-clip-test.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 6234aa2..d3d5bf1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,7 +1,8 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests) shared_tests = \ - config-parser.test + config-parser.test \ + vertex-clip.test module_tests = \ surface-test.la \ @@ -50,19 +51,11 @@ AM_CPPFLAGS = \ -DUNIT_TEST \ $(COMPOSITOR_CFLAGS) - -config_parser_test_LDADD = \ - ../shared/libshared.la \ - $(COMPOSITOR_LIBS) -config_parser_test_SOURCES = \ - config-parser-test.c - surface_global_test_la_SOURCES = surface-global-test.c surface_global_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) surface_test_la_SOURCES = surface-test.c surface_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) -weston_test = weston-test.la weston_test_la_LIBADD = $(COMPOSITOR_LIBS) \ ../shared/libshared.la weston_test_la_LDFLAGS = -module -avoid-version -rpath $(libdir) @@ -75,17 +68,37 @@ weston_test_la_SOURCES =\ weston_test_runner_src = \ weston-test-runner.c\ weston-test-runner.h + +check_LTLIBRARIES = libshared_test.a + +libshared_test_a_SOURCES = \ + $(weston_test_runner_src) +libshared_test_a_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) + +config_parser_test_LDADD = \ + ../shared/libshared.la \ + libshared_test.a\ + $(COMPOSITOR_LIBS) +config_parser_test_SOURCES = \ + config-parser-test.c +vertex_clip_test_SOURCES = \ + vertex-clip-test.c +vertex_clip_test_LDADD = \ + ../shared/libshared.la \ + libshared_test.a\ + -lm -lrt + weston_test_client_src = \ weston-test-client-helper.c \ weston-test-client-helper.h \ wayland-test-protocol.c \ wayland-test-client-protocol.h \ subsurface-protocol.c \ - subsurface-client-protocol.h\ - $(weston_test_runner_src) + subsurface-client-protocol.h weston_test_client_libs = \ $(SIMPLE_CLIENT_LIBS) \ - ../shared/libshared.la + ../shared/libshared.la \ + libshared_test.a keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src) keyboard_weston_LDADD = $(weston_test_client_libs) diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c new file mode 100644 index 000..51188b2 --- /dev/null +++ b/tests/vertex-clip-test.c @@ -0,0 +1,219 @@ +/* + * Copyright © 2013 Sam Spilsbury smspil...@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. + */ +#include assert.h +#include stdio.h +#include stdlib.h +#include string.h +#include math.h + +#include weston-test-runner.h + +#include ../shared/vertex-clipping.h + +#define BOUNDING_BOX_TOP_Y 100.0f +#define BOUNDING_BOX_LEFT_X 50.0f +#define BOUNDING_BOX_RIGHT_X 100.0f +#define BOUNDING_BOX_BOTTOM_Y 50.0f + +#define INSIDE_X1 (BOUNDING_BOX_LEFT_X + 1.0f) +#define INSIDE_X2 (BOUNDING_BOX_RIGHT_X - 1.0f) +#define INSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y + 1.0f) +#define INSIDE_Y2 (BOUNDING_BOX_TOP_Y - 1.0f) + +#define OUTSIDE_X1 (BOUNDING_BOX_LEFT_X - 1.0f
Re: [PATCH 1/3] Add support for table-driven testing.
Hi,
On Wed, Sep 11, 2013 at 1:37 AM, Eoff, Ullysses A
ullysses.a.e...@intel.com wrote:
-Original Message-
From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org
[mailto:wayland-devel-
bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Sam
Spilsbury
Sent: Tuesday, September 10, 2013 9:15 AM
To: wayland-devel@lists.freedesktop.org
Cc: Sam Spilsbury
Subject: [PATCH 1/3] Add support for table-driven testing.
The new TEST_P macro takes a function name and a data argument to
point to an arbitrary array of known size of test data. This allows
multiple tests to be run with different datasets. The array is stored
as a void * but advanced by a known size on each iteration.
The data for each invocation of the test is provided as a data argument,
it is the responsibility of the test to cast it to something sensible.
---
tests/weston-test-runner.c | 117
-
tests/weston-test-runner.h | 52 +---
2 files changed, 108 insertions(+), 61 deletions(-)
diff --git a/tests/weston-test-runner.c b/tests/weston-test-runner.c
index 27ea9e4..1eb93ea 100644
--- a/tests/weston-test-runner.c
+++ b/tests/weston-test-runner.c
@@ -46,18 +46,81 @@ find_test(const char *name)
}
static void
-run_test(const struct weston_test *t)
+run_test(const struct weston_test *t, void *data)
{
- t-run();
+ t-run(data);
exit(EXIT_SUCCESS);
}
+static int
+exec_and_report_test(const struct weston_test *t, void *test_data, int
iteration)
+{
+ int success = 0;
+ int hardfail = 0;
+ siginfo_t info;
+
+ pid_t pid = fork();
+ assert(pid = 0);
+
+ if (pid == 0)
+ run_test(t, test_data); /* never returns */
+
+ if (waitid(P_ALL, 0, info, WEXITED)) {
+ fprintf(stderr, waitid failed: %m\n);
+ abort();
+ }
+
+ if (test_data)
+ fprintf(stderr, test \%s/%i\:\t, t-name, iteration);
+ else
+ fprintf(stderr, test \%s\:\t, t-name);
+
+ switch (info.si_code) {
+ case CLD_EXITED:
+ fprintf(stderr, exit status %d, info.si_status);
+ if (info.si_status == EXIT_SUCCESS)
+ success = 1;
+ break;
+ case CLD_KILLED:
+ case CLD_DUMPED:
+ fprintf(stderr, signal %d, info.si_status);
+ if (info.si_status != SIGABRT)
+ hardfail = 1;
+ break;
+ }
+
+ if (t-must_fail)
+ success = !success;
+
+ if (success !hardfail) {
+ fprintf(stderr, , pass.\n);
+ return 1;
+ } else {
+ fprintf(stderr, , fail.\n);
+ return 0;
+ }
+}
+
+/* Returns number of tests and number of pass / fail in param args */
+static int
+iterate_test(const struct weston_test *t, int *passed)
+{
+ int i;
+ void *current_test_data = (void *) t-table_data;
+ for (i = 0; i t-n_elements; ++i, current_test_data +=
t-element_size)
+ {
+ if (exec_and_report_test(t, current_test_data, i))
+ ++(*passed);
+ }
+
+ return t-n_elements;
+}
+
int main(int argc, char *argv[])
{
const struct weston_test *t;
- pid_t pid;
- int total, pass;
- siginfo_t info;
+ int total = 0;
+ int pass = 0;
if (argc == 2) {
t = find_test(argv[1]);
@@ -66,51 +129,15 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
- run_test(t);
+ run_test(t, (void *) t-table_data);
Should we be iterating though each table_data element here, too?
We do actually, see here:
+ int i;
+ void *current_test_data = (void *) t-table_data;
+ for (i = 0; i t-n_elements; ++i, current_test_data +=
t-element_size)
+ {
+ if (exec_and_report_test(t, current_test_data, i))
+ ++(*passed);
+ }
It just isn't particularly obvious because current_test_data is
advanced in the iteration condition of the loop. Should that be
changed?
}
- pass = 0;
for (t = __start_test_section; t __stop_test_section; t++) {
- int success = 0;
- int hardfail = 0;
-
- pid = fork();
- assert(pid = 0);
-
- if (pid == 0)
- run_test(t); /* never returns */
-
- if (waitid(P_ALL, 0, info, WEXITED)) {
- fprintf(stderr, waitid failed: %m\n);
- abort();
- }
-
- fprintf(stderr, test \%s\:\t, t-name);
- switch (info.si_code) {
- case CLD_EXITED
Re: [PATCH 3/3] Added tests for the vertex clipping code.
Hi, On Wed, Sep 11, 2013 at 1:33 AM, Eoff, Ullysses A ullysses.a.e...@intel.com wrote: -Original Message- From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org [mailto:wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Sam Spilsbury Sent: Tuesday, September 10, 2013 9:15 AM To: wayland-devel@lists.freedesktop.org Cc: Sam Spilsbury Subject: [PATCH 3/3] Added tests for the vertex clipping code. This tests (via the table-driven testing method) that the correct number of vertices and also the correct vertices themselves are generated for an clip box and polygon of up to eight vertices. --- tests/Makefile.am| 11 ++- tests/vertex-clip-test.c | 219 +++ 2 files changed, 229 insertions(+), 1 deletion(-) create mode 100644 tests/vertex-clip-test.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 82bf630..336c5f9 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -2,6 +2,7 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests) shared_tests = \ config-parser.test + vertex-clipping.test You're missing a line continuation \ after config-parser.test Also, I don't see vertex_clipping_test_SOURCES, etc... sections defined. Noted, line continuation added in the next series. vertex_clip_SOURCES is there: +vertex_clip_test_SOURCES =\ +vertex-clip-test.c\ +$(top_srcdir)/shared/vertex-clipping.c\ +$(top_srcdir)/shared/vertex-clipping.h\ +$(weston_test_runner_src) +vertex_clip_test_LDADD = -lm -lrt module_tests = \ surface-test.la \ @@ -33,7 +34,8 @@ noinst_LTLIBRARIES =\ noinst_PROGRAMS =\ $(setbacklight) \ - matrix-test + matrix-test \ + vertex-clip-test Hmm... do you want to have vertex-clip-test (i.e. vertex-clipping.test) to be part of the shared_tests so that it gets executed by make check? matrix-test and backlight-test are only defined this way because they are legacy tests that never got converted to runner style tests when that test framework was introduced :-/. I agree and was just thinking about that last night. I've added it to the shared_tests in the next series (it should have been, and the target name was wrong I guess). check_LTLIBRARIES = \ $(module_tests) @@ -84,6 +86,13 @@ weston_test_client_libs = \ $(SIMPLE_CLIENT_LIBS) \ ../shared/libshared.la +vertex_clip_test_SOURCES = \ + vertex-clip-test.c \ + $(top_srcdir)/shared/vertex-clipping.c \ + $(top_srcdir)/shared/vertex-clipping.h \ + $(weston_test_runner_src) +vertex_clip_test_LDADD = -lm -lrt + keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src) keyboard_weston_LDADD = $(weston_test_client_libs) diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c new file mode 100644 index 000..51188b2 --- /dev/null +++ b/tests/vertex-clip-test.c @@ -0,0 +1,219 @@ +/* + * Copyright © 2013 Sam Spilsbury smspil...@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. + */ +#include assert.h +#include stdio.h +#include stdlib.h +#include string.h +#include math.h + +#include weston-test-runner.h + +#include ../shared/vertex-clipping.h + +#define BOUNDING_BOX_TOP_Y 100.0f +#define BOUNDING_BOX_LEFT_X 50.0f +#define BOUNDING_BOX_RIGHT_X 100.0f +#define BOUNDING_BOX_BOTTOM_Y 50.0f + +#define INSIDE_X1 (BOUNDING_BOX_LEFT_X + 1.0f) +#define INSIDE_X2 (BOUNDING_BOX_RIGHT_X - 1.0f) +#define INSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y + 1.0f) +#define INSIDE_Y2 (BOUNDING_BOX_TOP_Y
[PATCH 0/3] Tests for vertex clipping (v2)
This patch series adds some tests for the vertex clipping code. It splits the main parts of calculate_edges out into clip_transformed exported in shared/vertex-clipping.c and adds support for table-driven testing in tests/weston-test-runner.h . Finally, it makes weston-test-runner.c compile into libshared_test.a so that we don't need to recompile it all the time Sam Spilsbury (3): Add support for table-driven testing. Split vertex clipping code out into vertex-clipping.c in shared/ Added tests for the vertex clipping code. shared/Makefile.am | 4 +- shared/vertex-clipping.c | 317 + shared/vertex-clipping.h | 65 ++ src/gl-renderer.c | 292 + tests/Makefile.am | 41 -- tests/vertex-clip-test.c | 219 +++ tests/weston-test-runner.c | 117 ++--- tests/weston-test-runner.h | 52 +--- 8 files changed, 744 insertions(+), 363 deletions(-) create mode 100644 shared/vertex-clipping.c create mode 100644 shared/vertex-clipping.h create mode 100644 tests/vertex-clip-test.c -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] Add support for table-driven testing.
/weston-test-runner.h b/tests/weston-test-runner.h
index 41df386..457cf31 100644
--- a/tests/weston-test-runner.h
+++ b/tests/weston-test-runner.h
@@ -1,5 +1,6 @@
/*
* Copyright © 2012 Intel Corporation
+ * Copyright © 2013 Sam Spilsbury smspil...@gmail.com
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
@@ -23,34 +24,53 @@
#ifndef _WESTON_TEST_RUNNER_H_
#define _WESTON_TEST_RUNNER_H_
+#include stdlib.h
+
#ifdef NDEBUG
#error Tests must not be built with NDEBUG defined, they rely on assert().
#endif
struct weston_test {
const char *name;
- void (*run)(void);
+ void (*run)(void *);
+ const void *table_data;
+ size_t element_size;
+ int n_elements;
int must_fail;
-} __attribute__ ((aligned (16)));
+} __attribute__ ((aligned (32)));
-#define TEST(name) \
- static void name(void); \
+#define TEST_BEGIN(name, arg) \
+ static void name(arg)
+
+#define TEST_COMMON(func, name, ret, data, size, n_elem) \
+ static void func(void *); \
\
const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 0 \
- }; \
- \
- static void name(void)
+ __attribute__ ((section (test_section))) =\
+ { \
+ #name, func, data, size, n_elem, ret\
+ };
-#define FAIL_TEST(name)\
+#define NO_ARG_TEST(name, ret) \
+ TEST_COMMON(wrap##name, name, ret, NULL, 0, 1) \
static void name(void); \
+ static void wrap##name(void *data) \
+ { \
+ (void) data;\
+ name(); \
+ } \
\
- const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 1 \
- }; \
- \
- static void name(void)
+ TEST_BEGIN(name, void)
+
+#define ARG_TEST(name, ret, test_data) \
+ TEST_COMMON(name, name, ret, test_data, \
+ sizeof(test_data[0]), \
+ sizeof(test_data) / sizeof (test_data[0])) \
+ TEST_BEGIN(name, void *data)\
+
+#define TEST(name) NO_ARG_TEST(name, 0)
+#define FAIL_TEST(name) NO_ARG_TEST(name, 1)
+#define TEST_P(name, data) ARG_TEST(name, 0, data)
+#define FAIL_TEST_P(name, data) ARG_TEST(name, 1, data)
#endif
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] Added tests for the vertex clipping code.
This tests (via the table-driven testing method) that the correct number of vertices and also the correct vertices themselves are generated for an clip box and polygon of up to eight vertices. Also add a libshared_test.a so that we don't have to build weston-test-runner all the time --- tests/Makefile.am| 41 ++--- tests/vertex-clip-test.c | 219 +++ 2 files changed, 247 insertions(+), 13 deletions(-) create mode 100644 tests/vertex-clip-test.c diff --git a/tests/Makefile.am b/tests/Makefile.am index 82bf630..18a81b1 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,7 +1,8 @@ TESTS = $(shared_tests) $(module_tests) $(weston_tests) shared_tests = \ - config-parser.test + config-parser.test \ + vertex-clip.test module_tests = \ surface-test.la \ @@ -51,15 +52,6 @@ AM_CPPFLAGS =\ $(COMPOSITOR_CFLAGS) AM_LDFLAGS = -module -avoid-version -rpath $(libdir) -config_parser_test_LDADD = \ - ../shared/libshared.la \ - $(COMPOSITOR_LIBS) -config_parser_test_SOURCES = \ - config-parser-test.c - -surface_global_test_la_SOURCES = surface-global-test.c -surface_test_la_SOURCES = surface-test.c - weston_test = weston-test.la weston_test_la_LIBADD = $(COMPOSITOR_LIBS) \ ../shared/libshared.la @@ -69,20 +61,43 @@ weston_test_la_SOURCES =\ wayland-test-protocol.c \ wayland-test-server-protocol.h +surface_global_test_la_SOURCES = surface-global-test.c +surface_test_la_SOURCES = surface-test.c + weston_test_runner_src = \ weston-test-runner.c\ weston-test-runner.h + +check_LTLIBRARIES = libshared_test.a + +libshared_test_a_SOURCES = \ + $(weston_test_runner_src) +libshared_test_a_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) + +config_parser_test_LDADD = \ + ../shared/libshared.la \ + libshared_test.a\ + $(COMPOSITOR_LIBS) +config_parser_test_SOURCES = \ + config-parser-test.c +vertex_clip_test_SOURCES = \ + vertex-clip-test.c +vertex_clip_test_LDADD = \ + ../shared/libshared.la \ + libshared_test.a\ + -lm -lrt + weston_test_client_src = \ weston-test-client-helper.c \ weston-test-client-helper.h \ wayland-test-protocol.c \ wayland-test-client-protocol.h \ subsurface-protocol.c \ - subsurface-client-protocol.h\ - $(weston_test_runner_src) + subsurface-client-protocol.h weston_test_client_libs = \ $(SIMPLE_CLIENT_LIBS) \ - ../shared/libshared.la + ../shared/libshared.la \ + libshared_test.a keyboard_weston_SOURCES = keyboard-test.c $(weston_test_client_src) keyboard_weston_LDADD = $(weston_test_client_libs) diff --git a/tests/vertex-clip-test.c b/tests/vertex-clip-test.c new file mode 100644 index 000..51188b2 --- /dev/null +++ b/tests/vertex-clip-test.c @@ -0,0 +1,219 @@ +/* + * Copyright © 2013 Sam Spilsbury smspil...@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. + */ +#include assert.h +#include stdio.h +#include stdlib.h +#include string.h +#include math.h + +#include weston-test-runner.h + +#include ../shared/vertex-clipping.h + +#define BOUNDING_BOX_TOP_Y 100.0f +#define BOUNDING_BOX_LEFT_X 50.0f +#define BOUNDING_BOX_RIGHT_X 100.0f +#define BOUNDING_BOX_BOTTOM_Y 50.0f + +#define INSIDE_X1 (BOUNDING_BOX_LEFT_X + 1.0f) +#define INSIDE_X2 (BOUNDING_BOX_RIGHT_X - 1.0f) +#define INSIDE_Y1 (BOUNDING_BOX_BOTTOM_Y + 1.0f) +#define INSIDE_Y2 (BOUNDING_BOX_TOP_Y - 1.0f) + +#define OUTSIDE_X1 (BOUNDING_BOX_LEFT_X - 1.0f) +#define OUTSIDE_X2
[PATCH 2/3] Split vertex clipping code out into vertex-clipping.c in shared/
---
shared/Makefile.am | 4 +-
shared/vertex-clipping.c | 317 +++
shared/vertex-clipping.h | 65 ++
src/gl-renderer.c| 292 +--
4 files changed, 389 insertions(+), 289 deletions(-)
create mode 100644 shared/vertex-clipping.c
create mode 100644 shared/vertex-clipping.h
diff --git a/shared/Makefile.am b/shared/Makefile.am
index 2fcff7b..f1abc61 100644
--- a/shared/Makefile.am
+++ b/shared/Makefile.am
@@ -7,7 +7,9 @@ libshared_la_SOURCES = \
option-parser.c \
config-parser.h \
os-compatibility.c \
- os-compatibility.h
+ os-compatibility.h \
+ vertex-clipping.c \
+ vertex-clipping.h
libshared_cairo_la_CFLAGS =\
$(GCC_CFLAGS) \
diff --git a/shared/vertex-clipping.c b/shared/vertex-clipping.c
new file mode 100644
index 000..603ce6f
--- /dev/null
+++ b/shared/vertex-clipping.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ *
+ * 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.
+ */
+#include assert.h
+#include float.h
+#include math.h
+
+#include GLES2/gl2.h
+
+#include vertex-clipping.h
+
+GLfloat
+float_difference(GLfloat a, GLfloat b)
+{
+ /*
http://www.altdevblogaday.com/2012/02/22/comparing-floating-point-numbers-2012-edition/
*/
+ static const GLfloat max_diff = 4.0f * FLT_MIN;
+ static const GLfloat max_rel_diff = 4.0e-5;
+ GLfloat diff = a - b;
+ GLfloat adiff = fabsf(diff);
+
+ if (adiff = max_diff)
+ return 0.0f;
+
+ a = fabsf(a);
+ b = fabsf(b);
+ if (adiff = (a b ? a : b) * max_rel_diff)
+ return 0.0f;
+
+ return diff;
+}
+
+/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line x = x_arg.
+ * Compute the y coordinate of the intersection.
+ */
+static GLfloat
+clip_intersect_y(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
+GLfloat x_arg)
+{
+ GLfloat a;
+ GLfloat diff = float_difference(p1x, p2x);
+
+ /* Practically vertical line segment, yet the end points have already
+* been determined to be on different sides of the line. Therefore
+* the line segment is part of the line and intersects everywhere.
+* Return the end point, so we use the whole line segment.
+*/
+ if (diff == 0.0f)
+ return p2y;
+
+ a = (x_arg - p2x) / diff;
+ return p2y + (p1y - p2y) * a;
+}
+
+/* A line segment (p1x, p1y)-(p2x, p2y) intersects the line y = y_arg.
+ * Compute the x coordinate of the intersection.
+ */
+static GLfloat
+clip_intersect_x(GLfloat p1x, GLfloat p1y, GLfloat p2x, GLfloat p2y,
+GLfloat y_arg)
+{
+ GLfloat a;
+ GLfloat diff = float_difference(p1y, p2y);
+
+ /* Practically horizontal line segment, yet the end points have already
+* been determined to be on different sides of the line. Therefore
+* the line segment is part of the line and intersects everywhere.
+* Return the end point, so we use the whole line segment.
+*/
+ if (diff == 0.0f)
+ return p2x;
+
+ a = (y_arg - p2y) / diff;
+ return p2x + (p1x - p2x) * a;
+}
+
+enum path_transition {
+ PATH_TRANSITION_OUT_TO_OUT = 0,
+ PATH_TRANSITION_OUT_TO_IN = 1,
+ PATH_TRANSITION_IN_TO_OUT = 2,
+ PATH_TRANSITION_IN_TO_IN = 3,
+};
+
+static void
+clip_append_vertex(struct clip_context *ctx, GLfloat x, GLfloat y)
+{
+ *ctx-vertices.x++ = x;
+ *ctx-vertices.y++ = y;
+}
+
+static enum path_transition
+path_transition_left_edge(struct clip_context *ctx, GLfloat x, GLfloat y)
+{
+
[PATCH 1/3] Add support for table-driven testing.
++;
- fprintf(stderr, , pass.\n);
- } else
- fprintf(stderr, , fail.\n);
}
- total = __stop_test_section - __start_test_section;
fprintf(stderr, %d tests, %d pass, %d fail\n,
total, pass, total - pass);
diff --git a/tests/weston-test-runner.h b/tests/weston-test-runner.h
index 41df386..457cf31 100644
--- a/tests/weston-test-runner.h
+++ b/tests/weston-test-runner.h
@@ -1,5 +1,6 @@
/*
* Copyright © 2012 Intel Corporation
+ * Copyright © 2013 Sam Spilsbury smspil...@gmail.com
*
* Permission to use, copy, modify, distribute, and sell this software and
* its documentation for any purpose is hereby granted without fee, provided
@@ -23,34 +24,53 @@
#ifndef _WESTON_TEST_RUNNER_H_
#define _WESTON_TEST_RUNNER_H_
+#include stdlib.h
+
#ifdef NDEBUG
#error Tests must not be built with NDEBUG defined, they rely on assert().
#endif
struct weston_test {
const char *name;
- void (*run)(void);
+ void (*run)(void *);
+ const void *table_data;
+ size_t element_size;
+ int n_elements;
int must_fail;
-} __attribute__ ((aligned (16)));
+} __attribute__ ((aligned (32)));
-#define TEST(name) \
- static void name(void); \
+#define TEST_BEGIN(name, arg) \
+ static void name(arg)
+
+#define TEST_COMMON(func, name, ret, data, size, n_elem) \
+ static void func(void *); \
\
const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 0 \
- }; \
- \
- static void name(void)
+ __attribute__ ((section (test_section))) =\
+ { \
+ #name, func, data, size, n_elem, ret\
+ };
-#define FAIL_TEST(name)\
+#define NO_ARG_TEST(name, ret) \
+ TEST_COMMON(wrap##name, name, ret, NULL, 0, 1) \
static void name(void); \
+ static void wrap##name(void *data) \
+ { \
+ (void) data;\
+ name(); \
+ } \
\
- const struct weston_test test##name \
-__attribute__ ((section (test_section))) = { \
- #name, name, 1 \
- }; \
- \
- static void name(void)
+ TEST_BEGIN(name, void)
+
+#define ARG_TEST(name, ret, test_data) \
+ TEST_COMMON(name, name, ret, test_data, \
+ sizeof(test_data[0]), \
+ sizeof(test_data) / sizeof (test_data[0])) \
+ TEST_BEGIN(name, void *data)\
+
+#define TEST(name) NO_ARG_TEST(name, 0)
+#define FAIL_TEST(name) NO_ARG_TEST(name, 1)
+#define TEST_P(name, data) ARG_TEST(name, 0, data)
+#define FAIL_TEST_P(name, data) ARG_TEST(name, 1, data)
#endif
--
1.8.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clarifying scope and goals for weston
On Wed, May 1, 2013 at 2:01 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: On Fri, Apr 19, 2013 at 11:03:16PM -0700, Kenneth Graunke wrote: On 04/18/2013 12:04 AM, Sam Spilsbury wrote: On Wed, Apr 17, 2013 at 1:34 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: [snip] Toolkit type scenegraphs (QML, Clutter) has a lot of flexibility that tend to get in the way when trying to reason about occlusion and coverage. Bandwidth saving optimizations such as clipping obscured damage or splitting the surfaces into opaque and transparent primitives just seem out of reach when you have to deal with general 3D objects and punch through several layers of abstractions. This is true. I don't really think that providing rendering libraries would make a whole lot of sense for existing scene graphs. But it would make sense for other window managers which don't currently provide any kind of compositing story at all. Perhaps this is worth doing some prototyping around to see what does and does not make sense to split out? I'll put my hand up to volunteer, but my time is pretty limited these days so I'm not so sure how much I will be able to put into it. Kristian -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] [tests] Running the wayland tests against compositor-headless
On Mon, Apr 22, 2013 at 11:02 PM, Eoff, Ullysses A ullysses.a.e...@intel.com wrote: -Original Message- From: Sam Spilsbury [mailto:smspil...@gmail.com] snip snip Yes, it would be trivial to enable the input-based tests to run on the headless backend... however, it's unclear to me whether the headless backend should be the one responsible for initializing/tracking the keyboard and pointer inputs. That kinda feels counter intuitive to the definition of headless (but perhaps not :-/). Maybe we could have the weston-test extension module initialize the inputs in an idle loop callback, for example if the output-model == headless, then do: weston_seat_init_pointer(seat); weston_seat_init_keyboard(seat, NULL); They'll probably need to be lazy-initialized at least. At the moment weston is segfaulting because the tests trigger callbacks in weston that expect the pointer and keyboard interfaces to be present on a seat. Either that or a headless seat implementation might be in order. For the other two, which ones are they and what kind of protocol support is lacking? Perhaps there is another way we can get them to work on headless? The broader reason I'm looking into this is because I want to see if we can eventually export the weston-test module as part of the installation as well as the headless and no-op backends so that applications can run integration tests against weston to verify that they handle input, shell surface changes etc correctly. I'm looking into doing some GSoC work on a project where I suspect that the wayland backend will not be run all the time, and it will be good to have integration tests in place to ensure that it doesn't break accidentally because developers may not be able to run it regularly. The headless backend module gets installed, already. But if you're also talking about exporting headless backend header(s), then I'm willing to bet that won't happen. As for the weston-test module being exported (module and headers), that would have to be the maintainer's decision (Kristian; aka, krh) and/or a consensus from other community contributors. If nothing else, you can always write your own test extension, too, that will enable you to do integration testing on your particular application use-cases. Lets have a discussion about this when Kristian gets back. I think having an upstreamed module providing wl_test will be beneficial for lots of downstream application developers because it means they can use some common protocol which they know works and integrate that into their applications. In the event that we don't want to do that, another alternative would be to look into making weston-test an external module as part of a broader external modules proposal so it can have its own direction in terms of what it supports. Of course the final alternative is to just have applications ship their own modules and test protocols, but this is not really ideal. So - shall I create and submit some patches to get the tests working on headless? I suppose this is a desirable thing right? I wouldn't be the one to make the ultimate decision on their inclusions into upstream. It'd be nice to hear what others think about this topic, too. Either way, it wouldn't hurt to send patches for review, feedback, and discussion... even if they end up getting rejected for a different solution ;). I'll write up some patches ASAP. Best, Sam snip Cheers, U. Artie Thanks, Sam -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] [tests] Running the wayland tests against compositor-headless
On Mon, Apr 22, 2013 at 3:48 PM, Eoff, Ullysses A ullysses.a.e...@intel.com wrote: -Original Message- From: wayland-devel-bounces+ullysses.a.eoff=intel@lists.freedesktop.org [mailto:wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Eoff, Ullysses A Sent: Monday, April 22, 2013 1:24 PM To: Sam Spilsbury; wayland Subject: RE: [RFC] [tests] Running the wayland tests against compositor-headless Changing the tests to run headless is probably not necessary... To clarify... I only meant this in the context of the weston-tests-env script , i.e. it does not need to be changed in order for you to automate 'make check' to run them on headless ;) Ah interesting. I guess the point of the tests is to verify the backends themselves as opposed to testing the core compositor (well, it tests that as an incident, but I guess its not the point?). Does it make sense to have also acceptance tests which really only verify the core behavior of weston and not the backends themselves? ...but if it's a problem that the tests themselves can't run on the headless backend, then changing those in a way to work on headless, too, might be useful. So at the moment - they aren't - well, its possible to run the two library based ones. 3 of the client based ones are easy to enable, as for the other three, two of them protocol support from the backend, the other one (xwayland) doesn't really make sense on headless. The broader reason I'm looking into this is because I want to see if we can eventually export the weston-test module as part of the installation as well as the headless and no-op backends so that applications can run integration tests against weston to verify that they handle input, shell surface changes etc correctly. I'm looking into doing some GSoC work on a project where I suspect that the wayland backend will not be run all the time, and it will be good to have integration tests in place to ensure that it doesn't break accidentally because developers may not be able to run it regularly. So - shall I create and submit some patches to get the tests working on headless? I suppose this is a desirable thing right? Best, Sam You can create your own custom check script if weston-test-env does not suite your needs. To use it with make check, just set/export the LOG_COMPILER environment variable to refer to that script before running make check. make check just invokes your LOG_COMPILER script with the current test as an argument and then uses your scripts exitcode to determine pass/fail status. See http://www.gnu.org/software/automake/manual/html_node/Parallel- Test-Harness.html I use a custom python script in this manner so that I can run the tests on both Weston drm and x11 backends per test with only one invocation of make check. My custom script also allows me to parse the test output/results into a standard, normalized Xml format that is recognized by our continuous integration server. U. Artie Eoff -Original Message- From: wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org [mailto:wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Sam Spilsbury Sent: Monday, April 22, 2013 11:50 AM To: wayland Subject: [RFC] [tests] Running the wayland tests against compositor-headless Hi, I'm not sure if this is a work-item that's already in-progress by somebody. I noticed that weston has a headless compositor backend and a no-op renderer, which effectively do not depend on having OpenGL or *a* windowing system available at the time that weston is run. It would be really great if we could run the tests against this backend, because then it means that they can be run on foreign machines like continuous integration servers with ease. I've tried quickly changing the backend over in weston-test-env - currently most of the tests are failing because client-pointer is not initialized. Upon initializing that, most of them pass except those that depend on client-keyboard . I suspect that this will involve having to create a wl_keyboard with a set of dummy xkb data for layouts, though I'm not sure how to do that yet. My question to the list is - does it make sense to submit a patch to change the tests over to use the headless backend? Or is the preference to keep them using the wayland or x11 backend for now. Best, Sam. -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org
Re: [RFC] [tests] Running the wayland tests against compositor-headless
So - shall I create and submit some patches to get the tests working on headless? I suppose this is a desirable thing right? Ah, to clarify this point - I meant submitting patches which would allow the headless backend to be used in testing, as opposed to just x11 and drm. Best, Sam You can create your own custom check script if weston-test-env does not suite your needs. To use it with make check, just set/export the LOG_COMPILER environment variable to refer to that script before running make check. make check just invokes your LOG_COMPILER script with the current test as an argument and then uses your scripts exitcode to determine pass/fail status. See http://www.gnu.org/software/automake/manual/html_node/Parallel- Test-Harness.html I use a custom python script in this manner so that I can run the tests on both Weston drm and x11 backends per test with only one invocation of make check. My custom script also allows me to parse the test output/results into a standard, normalized Xml format that is recognized by our continuous integration server. U. Artie Eoff -Original Message- From: wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org [mailto:wayland-devel- bounces+ullysses.a.eoff=intel@lists.freedesktop.org] On Behalf Of Sam Spilsbury Sent: Monday, April 22, 2013 11:50 AM To: wayland Subject: [RFC] [tests] Running the wayland tests against compositor-headless Hi, I'm not sure if this is a work-item that's already in-progress by somebody. I noticed that weston has a headless compositor backend and a no-op renderer, which effectively do not depend on having OpenGL or *a* windowing system available at the time that weston is run. It would be really great if we could run the tests against this backend, because then it means that they can be run on foreign machines like continuous integration servers with ease. I've tried quickly changing the backend over in weston-test-env - currently most of the tests are failing because client-pointer is not initialized. Upon initializing that, most of them pass except those that depend on client-keyboard . I suspect that this will involve having to create a wl_keyboard with a set of dummy xkb data for layouts, though I'm not sure how to do that yet. My question to the list is - does it make sense to submit a patch to change the tests over to use the headless backend? Or is the preference to keep them using the wayland or x11 backend for now. Best, Sam. -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
The original compiz implementation is written in C. At the very end of 2008, 12/24, Compiz++ was unveiled. Compiz++ was a C++ version of compiz that was intended to be more easily maintainable. Unfortunately, all of the plugins had to be ported. The majority of this work was done by an aspiring college student, Sam Spilsbury. Eventually, Canonical realized that they wanted to do Unity but didn't really have the manpower required to do something entirely original. instead, the ployed to use compiz as a base platform for their Unity implementation. To this day, I still do support in #compiz. These days, it's mostly complaints about how 0.9.x is broken in fundamental ways that make the desktop unusable. Canonical severely damaged the compiz image with their disruptive and ever-so-misleadingly-named, Unity idea. Now, users are completely confused as to why compiz no longer works and why the stable version remains unpackaged and unused by distributions. It is noteworthy, that the original C implementation still works great to this day. The latest version is 0.8.9 and it can be found in the compiz-0.8 branches of compiz master. If anyone wants to help the compiz situation immediately, please go get this code and package it for ubuntu cgit.compiz.org http://wiki.compiz.org/Installation/Stable as many users will appreciate it. I know I would. I appreciate that you want to move forward, but there is no need to bash other projects or developers publicly, and incite animosity and disunity in those projects. Best Regards, Sam Sincerely, Scott Moreau ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Expected behaviour of eglSwapBuffers and the event queue
Hi, I'm a little confused on the behaviour of eglSwapBuffers operating on the event queue. At the moment, it calls wl_connection_read () on the display fd, which will read events into the local event buffer. I imagine it needs to do this in order to fetch some information about the next backbuffer from the compositor. However, it reads all of the events out of the queue, and this has pretty bad consequences for event loops which are trying to integrate the wayland fd into their poll () / select () loop. Because all of the data has been read from the fd, there is a condition where we have read every single event that needed to be delivered to us. Then when we return to poll (), it will block indefinitely because there is nothing left in the fd for us to read, and the compositor isn't going to send us any more events. It might be possible to work around this by checking if events are available in the queue and calling poll () if there aren't any, but it seems like there is no API available to do so. I wanted to know what the expected behaviour around this was meant to be. If eglSwapBuffers is meant to read () the fd, then that means that we need to rely on it being called in order to populate the event queue (since it can only be done in one place). That, in my opinion, feels like broken behaviour, because we might want to use the protocol to send data to clients which wouldn't necessarily result in a SwapBuffers, then those clients can't reliably call either wl_display_dispatch_pending () or wl_display_dispatch () with poll () because there's no way of knowing whether or not that fd is going to block indefinitely or not. I guess I can make a few suggestions here... 1. eglSwapBuffers could read a separate fd for new buffer info 2. We could add an API to determine how many events are in the queue right now without reading, though that wouldn't solve the poll () problem 3. For roundtrip and SwapBuffers, we could make the server put some data back into the fd indicating that the fd has been read and events were put into the queue. That way, when main loops call poll () again, they will see data is available for reading - wl_display_dispatch would read that data, find no new events and dispatch the existing queue. Then if we don't SwapBuffers again and truly have no remaining events to be delivered, the next call to poll () would truly sleep until there was. Best Regards, Sam -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Expected behaviour of eglSwapBuffers and the event queue
Hey, thanks for the followup On Fri, Mar 1, 2013 at 12:50 PM, Daniel Stone dan...@fooishbar.org wrote: Hi, snip I wanted to know what the expected behaviour around this was meant to be. If eglSwapBuffers is meant to read () the fd, then that means that we need to rely on it being called in order to populate the event queue (since it can only be done in one place). That, in my opinion, feels like broken behaviour, because we might want to use the protocol to send data to clients which wouldn't necessarily result in a SwapBuffers, then those clients can't reliably call either wl_display_dispatch_pending () or wl_display_dispatch () with poll () because there's no way of knowing whether or not that fd is going to block indefinitely or not. Huh? wl_display_dispatch_pending() never blocks. Hence the suggestion to call it immediately before going into epoll/poll/select. Hmm, now that I think about it again, I think this method could work (eg dispatch_pending - flush - poll/select), at least for the event loop I'm working with (SDL). It feels a little strange in glib's loop though, because you'd effectively be dispatching during a call to prepare (). I guess I can make a few suggestions here... 1. eglSwapBuffers could read a separate fd for new buffer info Can't be done, as there are no cross-client resources. Figured as much. 3. For roundtrip and SwapBuffers, we could make the server put some data back into the fd indicating that the fd has been read and events were put into the queue. That way, when main loops call poll () again, they will see data is available for reading - wl_display_dispatch would read that data, find no new events and dispatch the existing queue. Then if we don't SwapBuffers again and truly have no remaining events to be delivered, the next call to poll () would truly sleep until there was. Ugh, that sounds nasty and trouble-prone. Yeah, could be ugly. I'm wondering if that's how Xlib/xcb does it though - eg, you might make a request that requires a roundtrip, which would necessitate reading events out of the fd until you got your reply. If there were no more events delivered after that then surely we have to do something to ensure that clients don't block forever in poll (). Best, Sam Cheers, Daniel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window stacking
On Wed, Sep 14, 2011 at 11:35 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: Il giorno mer, 14/09/2011 alle 21.56 +0800, Sam Spilsbury ha scritto: On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak spit...@gmail.com wrote: Along with all the discussion about client-side decorations, there is also a need for client-side window stacking and mapping. In current window managers it is almost impossible to make multiple-window complex applications. For instance the Gimp has been forced to abandon this idea. And in professional software, especially stuff with Windows versions, every single program has resorted to a single tiled window that fills the screen. There may be reasons to not have such applications, but one reason was that it was virtually impossible to control the window stacking order using the window system api, which typically consisted only of the transient for (child on Windows) attribute, and in more recent desktops some keep on top flags. For Wayland I would like to see the following, all very similar to how resize is working out: 1. Part of the Wayland api is that all the windows displayed by the compositor are in a single list that defines their stacking order. The compositor is expected to obey this (though it can disobey to prevent devious clients from taking over the screen). 2. There is a *atomic* api by which a client can map, unmap, and change the stacking order of it's own windows. This is probably a put a above/below b call (where b==None puts it at the bottom/top), and some unmap/map calls. All the changes are applied at once so the compositor either produces the before or the after composite, but never any intermediate one. 3. Like resize, there is a compositor-client notify call that looks identical (though I don't think it has to support multiple changes). Client is expected to do the change, but may also move and map or unmap and restack other windows. For instance it can keep floating dialog boxes and toolbars atop it's main windows. It can also keep windows with different pixel sizes directly below windows so the user cannot see the video playback is different from the frame around it. 4. Also like resize, there is a client-compositor request call that looks just like the notify. The compositor is expected to respond with the notify call, though it may alter it to obey keep-on-top and other such rules. So this is essentially just like X11's synethetic ConfigureRequests and ConfigureNotify events delivered to clients. I don't think it makes sense to let clients have control of toplevel stacking. If they wanted to have window groups which are kept in sync, it seems to me to create a large buffer with a custom input shape (if such a thing exists in wayland) such that windows are raised and lowered in groups, rather than having to ask the window manager to fix the stacking every single time the user raises a toolbox window. (see the WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL nightmare that WM's have to deal with right now). Is it a nightmare, or is it a feature, that the WM decides the stacking order? Not all WM behave in same way, and most of them are customizable in some form, which is, IMHO, a benefit for the user, that can pick the behavior he prefers. I think having a single partially transparent window is a limitation and would not improve the story with stacking; plus it would increase the complexity of toolkits (just look at the amounts of code GDK has for client-side windows) The fact that the window manager does this stuff is not bad, what I was getting at was the way that the window manager is interfaced with at the moment. At the moment you do window management in X by making requests directly to the server and then some of them are redirected to the window manager and some of them are not. This means that window managers have very little control over what's actually going on. The largest problem a lot of window managers face is keeping the internal stack representation in sync with whats going on server-side, which involves a lot of timing-dependent code. Dependency resolution with transient and modal windows is also very difficult to get right as there are subtly different stacking rules of situations where clients create lots of windows for the same application. If the desired end result is to have those windows on the same layer it would make sense to have the client create a single surface and do the compositing by itself (the window management policy in this case can always be pushed out into a separate library, there is no need to have the toolkits manage this). A few other ideas: 1. It seems likely that this should be merged with the resizing requests, and with activate/deactivate and focus changes. All window management should be a single call that can make all changes to the windows, with matching request and notify calls
Re: seprate window management component
On Wed, Sep 14, 2011 at 11:19 PM, Michal Suchanek hramr...@centrum.cz wrote: Hello, On 14 September 2011 16:55, cat zixo...@gmail.com wrote: would it be to much trouble to make window management a proxy program? The wayland server has to know how the windows stack but the clients are not trusted to tell it how the windows should stack so either the server has to figure that out by itself or a separate privileged component (eg. a proxy or a plugin or attached process of some sort) would need to decide that. I thought that it would make sense to determine what policy needs to be decided by this manager and add protocol for it in Wayland even if the default implementation will just grant every request an application ever makes. When I asked about that it was not outright rejected but there was nobody else who though putting some structure into Wayland would be of any use. I guess this will be considered only after Wayland evolves so many warts as X has and putting some sanity in the protocol will be impossible at that point for reasons of backward compatibility and whatnot. The biggest problem with the X protocol is that you talk to the window manager by making requests to the server and having them redirected by the window manager. Then the window manager being priviledged for that window (see SubstructureRedirectMask) is able to make requests to the server and have them be processed without redirect. This approach is somewhat inflexible and brings problems with eg, override redirect windows and out-of-order bugs when processing ConfigureRequests for normal windows and only receiving a ConfigureNotify for override redirect windows. In any case, the protocol for talking to the window manager should be part of a separate API that functions outside of the compositor. I think whether or not this is done out of process or in process is simply a matter of implementation. (In this process at least, all window management related requests would go through the window management policy first, rather than having the situation where we do now where the window manager must process requests after the fact in some cases) Regards, Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window stacking
On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak spit...@gmail.com wrote: Along with all the discussion about client-side decorations, there is also a need for client-side window stacking and mapping. In current window managers it is almost impossible to make multiple-window complex applications. For instance the Gimp has been forced to abandon this idea. And in professional software, especially stuff with Windows versions, every single program has resorted to a single tiled window that fills the screen. There may be reasons to not have such applications, but one reason was that it was virtually impossible to control the window stacking order using the window system api, which typically consisted only of the transient for (child on Windows) attribute, and in more recent desktops some keep on top flags. For Wayland I would like to see the following, all very similar to how resize is working out: 1. Part of the Wayland api is that all the windows displayed by the compositor are in a single list that defines their stacking order. The compositor is expected to obey this (though it can disobey to prevent devious clients from taking over the screen). 2. There is a *atomic* api by which a client can map, unmap, and change the stacking order of it's own windows. This is probably a put a above/below b call (where b==None puts it at the bottom/top), and some unmap/map calls. All the changes are applied at once so the compositor either produces the before or the after composite, but never any intermediate one. 3. Like resize, there is a compositor-client notify call that looks identical (though I don't think it has to support multiple changes). Client is expected to do the change, but may also move and map or unmap and restack other windows. For instance it can keep floating dialog boxes and toolbars atop it's main windows. It can also keep windows with different pixel sizes directly below windows so the user cannot see the video playback is different from the frame around it. 4. Also like resize, there is a client-compositor request call that looks just like the notify. The compositor is expected to respond with the notify call, though it may alter it to obey keep-on-top and other such rules. So this is essentially just like X11's synethetic ConfigureRequests and ConfigureNotify events delivered to clients. I don't think it makes sense to let clients have control of toplevel stacking. If they wanted to have window groups which are kept in sync, it seems to me to create a large buffer with a custom input shape (if such a thing exists in wayland) such that windows are raised and lowered in groups, rather than having to ask the window manager to fix the stacking every single time the user raises a toolbox window. (see the WM_TRANSIENT_FOR and _NET_WM_STATE_MODAL nightmare that WM's have to deal with right now). A few other ideas: 1. It seems likely that this should be merged with the resizing requests, and with activate/deactivate and focus changes. All window management should be a single call that can make all changes to the windows, with matching request and notify calls. There should be a library function to concatenate window management messages so that a series of them can be turned into a final one which is the only one a program needs to obey. So essentially XConfigureWindow. I'm skeptical of having this built into the wayland protocol itself, mainly because I'm more of a fan of having window management done in a separate API to the windowing system, but I think those ideas need to be detailed later (and even then it's probably too late). 2. For task managers the windows are going to have to have some associated data with them, such as the text and icon, etc. Should this be in the wayland api, or should ipc from the task manager to the actual client be used? This should not be in the windowing system API since different environments may associate different data with applications or application groups. 3. Also for task managers it would be useful to make application windows that do not have images and never really map. These are displayed by task manager type applications. Requests to window-manage these should cause clients to also make related changes to visible windows. This is needed for multiple-window apis. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
the problem of not having a universal toolkit to handle these things, and the reality of the matter is that a lot of proprietary applications are not going to want to use these toolkits. You cannot assume that there will be a universally adopted method to styling because we see on every single platform that there will *not* be one. The best way to enforce styling is to enforce it at the window manager level, so that the applications on the system actually obey what the user wants them to do, not some crazy idea that the application developer had. Kind Regards, Sam -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
On Mon, Feb 21, 2011 at 3:35 AM, Enrico Weigelt weig...@metux.de wrote: * Marty Jack marty...@comcast.net schrieb: If remote clients is your thing, instead of forecasting doom because the old way may not work any more, first off, nothing stops someone from writing a thing that listens on port 6000 and acts just like a remote X server only it is a Wayland client, and second off, At this point, I fail to see the real benefit of Wayland, at least from user or infrastructure view. (yes, having the hw and composition part of the fat Xserver IMHO is a good thing from sw-architectural view). One thing that annoys me is that the current design papers explicitly take remoting out of the picture (almost declares that obsolete or tells people to use insufficient workarounds like VNC) and delegates a lot of things to individual clients (so in the end introducing massive code and data duplications). It really isn't that complicated. Just make a Netland server which manages your application's buffer and transmits it across the network to the other Netland server which then fills the buffer on the client machine. The whole reason remoting was taken out at the server level is because these days it accounts for a lot of the overhead you'll get with rendering, since the majority of clients will do all the surface painting Client-side (cairo, Qt) or direct to the hardware (OpenGL). For the case where the server and client are running on the same hardware, this is advantageous since you can actually have smooth rendering without round-tripping to the server all the time (which can only do things such as lines, fills, arcs and bitmap fills, the latter of which is used the most today). There isn't any way to describe something like a Gaussian blur to the server, and trying to add such things would only lead to an infinite expansion of the core protocol to try and describe every new drawing operation that someone comes up with. The other reason why remoting at a server level has become more useless is because people *are* choosing to use client-side rendering libraries like cairo and Qt and just sending the bitmaps to the X Server. In a network situation this drastically increases bandwidth usage, rather than the relatively small bandwidth operations such as lines, arcs and fills. So what we have now for networking is this sub-optimal mix of both round-tripping a lot when we don't need to (latency) /and/ high-bandwidth usage. nothing stops someone from redesigning and rethinking what the proper remote protocol is, I'd start with an proper model before starting to think about an specific protocol: why should a client still be responsible for drawing, instead of just describing what it wants to have displays (eg. an scene graph or something more hi-level) ? Typical GUI applications have concepts of windows (and windows within windows), widgets, etc. Those are all objects that can be described formally and rendered in a hi-level display server. This also would allow large savings of now heavily duplicated code and data in the individual clients. 8 1/2 could be a interesting conceptional starting point. This is indeed the kind of remoting that could be achieved at a toolkit level. using modern encryption and compression techniques and whatever else is needed to get a VNC like solution that performs well and is secure. VNC can not be done right that way, as it's conceptionally meant for a whole different purpose: it operates on screen level. It has no idea windows, server-side resource objects, etc. Simply lacks this information. Indeed, VNC is a bandwidth hog and not really useful for different media types. A good talk to watch on all of this remoting stuff is the talk that Adam Jackson gave at LCA a few weeks ago [1], he's working on SPICE and describes quite well all the different problems and solutions to doing display remoting. Regards, Sam [1] http://linuxconfau.blip.tv/file/4693225/ cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: What's wrong with wayland?
On Sat, Feb 19, 2011 at 1:59 PM, microcai micro...@fedoraproject.org wrote: I used to think wayland is better. But now, I don't. What is Wayland ? Let me tell you: Final Wayland = X11 that rip out everything but GLX. Current wayland still missing Input framework like XIM. And batch of other stuffs. Adding it will led wayland to another X11. I think these calls about how wayland is dommed to reinvent X11 are a bit unjustified. I think a more accurate thing to say is that wayland is going to become another display server which operates in similar ways to other display servers out there, like X11. But whatever happens, wayland is *not* going to become X11. X11 is designed around a networked display and window server protocol. It was core to the design of X11 that it managed the display hardware server-side, doing things such as mode-setting, indirect acceleration, and drawing primitives. It also managed (to some extent) what went into graphics memory. But the core part of X11 is that it only managed windows and pixmaps which were owned by clients running in different processes over a network protocol. The window manager and compositors are implemented externally, using that information from the server to blit the graphics on to the screen and actually change the size and position of the windows. The key difference with wayland is two-fold. First of all, it recognizes that server-side rendering is a bit useless and therefore having a network protocol so that you can do server-side rendering is also unnecessary overhead. Second of all, it integrates the window manager, compositing manager and window server into one process (through libwayland-compositor). This means that there is tighter integration between all three and that the window manager has greater control over what is going on server-side. Wayland forces every app uses OpenGL as drawing facility. Then they said, hey , mine are faster than you! Of-course wayland is faster! if X11 app also switch to OpenGL completely , X11 is also faster! Wayland requires that you render to a graphics buffer on the hardware (eg direct to memory that is accessible to the video card). Right now, these buffers are implemented by GEM or TTM. It just so happens that OpenGL ES provides us a quick, easy and portable way to render directly to these buffers using drawing commands directly on the video card. It is also likely that any other drawing frameworks are going to be implemented on top of OpenGL ES since that is the most portable way of implementing a draw-to-buffer method. What will make wayland's drawing implementation a lot faster than what we have with DRI2/X11 right now is that we don't need to worry about the server-side overhead of making pixmaps on the display server reference some buffer object in graphics memory - we can address these buffers directly. In addition, there are no more round-trips to the server to make anything in our GL implementation work, since the OpenGL ES is not windowing system dependent. needless to say , wayland has only one working driver, but X11 has a lot! All the driver needs to do is have DRM/DRI support, GLES support and pageflip support. And it just so happens that the open drivers either support this, or are gaining support for it very quickly. = That's what I'm now thinking about wayland, maybe I am wrong. And I hope I am wrong. Thanks for any comments. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Checklist: Programmer viewpoint
On Fri, Jan 28, 2011 at 2:42 AM, Marty Jack marty...@comcast.net wrote: Programmer viewpoint Are we having background pixmaps and borders? Should be always client drawn, yes? No implicit rendering, please. Implicit rendering was there during the time that core rendering was around to save bandwidth from server to client. Considering that clients now have direct access to buffers on the card, this is useless. Non-rectangular windows and an equivalent for the Shape extension I believe nonrectangular buffers are allowed no? Tracing, debugging, performance hooks libXtst, xev, xscope, x11perf This can all be done compositor side - since they get to watch the requests coming and the events coming out. Perhaps a library to export information about these events and requests would be useful though. (It does pose a security risk for, eg, keyloggers, so maybe we need to have some kind of security policy around this) Selections as distributed lock manager mediated by XServer Not aware of any examples outside of System Tray, XSettings, Compositing manager There was a proposed idea on wm-spec to do the same for desktop shells and the like. Perhaps this can be done over D-Bus. Use of root window properties and top-level application window properties as general inter-client communication Do an xprop -root and xprop on an application window on your favorite system to see how much this is used Window properties are nice, but they came from the day that X tried to do everything. Could we possibly have the window objects exported by the compositor over D-Bus and we can store properties on them that way? Seems a lot cleaner to me (rather than maintaining 2 property systems) Cheers, Sam ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Client side input processing
On Fri, Dec 10, 2010 at 10:21 PM, Marty Jack marty...@comcast.net wrote: There have been hints that client side input processing should be the norm in Wayland. This makes a lot of sense if client side drawing is the norm. This is a Big Decision with quite a lot of implications and it needs some design thought. Let's take a look at what input processing happens now in the X server - DPMS gets activated when there isn't any input for a time period - Screensaver gets activated when there isn't any input for a time period - Input device button remapping - Input device coordinate acceleration - Keyboard scan code to Unicode character plus modifiers, conditioned on a complex keyboard map - Keyboard autorepeat, including per-key configuration (this may be overkill now) - Accessibility features (StickyKeys, SlowKeys, MouseKeys, BounceKeys, etc.) - I am confident I have overlooked something For one thing, it means that all toolkits have to agree, and they all have to have code that implements the same semantics. Including, for example, the Wayland equivalent of FLTK, if such a thing were to exist, or an application that uses Wayland directly, like maybe a game. This makes the XSetting problem worse. Now, not only do we have My GTK theme is Daisies, please stored there, but we have all of this input-side configuration that absolutely has to be honored if keymaps or autorepeat or accessibility is going to work everywhere. So if this is going to be done, we need a good system-wide XSetting replacement. I wonder if shared memory isn't the way to go, if the drawing is done with shared memory transport. I don't think we want every client to be running the equivalent of setxkbmap and xkbcomp every time a client starts so it can do keyboard mapping. Concerning system wide inactivity timers: Right now there are two measures that I know of concerning system wide inactivity. One is measured by was there any activity on the input devices and controls DPMS and Screensaver. Sometimes it gets this wrong, such as when you are watching a movie, and there has been a workaround that disables the screensaver that things like movie players can use. Another is measured by was there a CPU load above a certain threshold that is used by the power manager to implement take this power action if the system is idle for this period. This can be wrong also, I had someone ask how to keep their system from hibernating while it was doing a long file transfer, that apparently didn't cause enough load to trigger the threshold. Also this requires the power manager to wake up often to take the load sample, which is counterproductive. It occurs to me that the kernel is is the best position to measure inactivity, if we were to rearchitect this a little. Client side input processing is problematic if you want to do any kind of meaningful input redirection on the side of the compositor. If the compositor cannot get all of the events first then this means that it cannot enforce certain window management policies. Regards, Sam ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sam Spilsbury ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
