Re: Vertex clipping and primitive types

[Sam Spilsbury]

On 20/09/2013 5:09 AM, "Bill Spitzak"  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

Re: Vertex clipping and primitive types

[Bill Spitzak]

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.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Vertex clipping and primitive types

[Jason Ekstrand]

On Wed, Sep 18, 2013 at 10:49 PM, Bill Spitzak  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".
>

Sorry about the delay.  I just responded to your previous e-mail.


> 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.
>
>
>  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.
>
>
>>
> __**_
> 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

Re: Vertex clipping and primitive types

[Sam Spilsbury]

Hi Bill,

On Sep 19, 2013 11:49 AM, "Bill Spitzak"  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: Vertex clipping and primitive types

[Bill Spitzak]

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".


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.



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.
  

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Vertex clipping and primitive types

[Sam Spilsbury]

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