[RFC weston] compositor: optimize/simplify shaders
rob.clark at linaro.org
Wed Aug 29 17:18:17 PDT 2012
On Tue, Aug 28, 2012 at 8:27 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 27 Aug 2012 17:03:10 +0300
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> Hi Rob,
>> I've started reviewing your patch and fixing the remaining bugs. So far
>> I think I got most of the blend/opaque region stuff sorted out. I
>> haven't still gotten to the geometry, where I can trigger visual bugs
>> with and without getting your TODO printouts.
>> I'm guessing the xwayland surfaces will come and haunt us, because I
>> think they contain both an opaque region with undefined alpha values,
>> and opaque and non-opaque regions with valid alpha values.I haven't
>> even tested them yet, but I guess a quick fix would be to paint opaque
>> regions always with a shader that forces texture alpha to 1.0. Would it
>> better as a different shader program or a uniform flag for a shader, I
>> don't know.
>> I'm not sure we should have nested functions in Weston code base. Also
>> like you noted, compositor_wayland.c does not build anymore.
>> Here's my WIP tree that may be rebased!
> The tree is still here and updated:
> I don't think I will be rebasing it anymore.
> I merged Rob's updates there.
> Rob, I will leave cleaning up the series for you, once we are done. You
> probably want to squash some things etc.
Fyi, I've squashed/reordered a bit. And pushed some nice updates to
your debug draw stuff, so now it is quite fun to look at:
>> I should get to reviewing the geometry tomorrow.
> I started on geometry, and wrote a simple debug feature:
> It draws the triangle edges. It's quite fun in realtime, apart from
> leaving a mess on the screen.
> When I was reading through the x1==x2 and y1==y2 special cases in
> calculate_edges(), I had the feeling the polygon winding order might
> get wrong sometimes. Also looking at it on paper I was certain I should
> be getting those TODO messages.
> Turned out the (!es->transform.enabled) special case was hiding all
> that. When forcing the transformed path, there's obviously something
> not quite right:
> That is in my git branch, too.
> There is also room for a simplification: as the intersection of two
> rectangles is guaranteed to be convex, we don't need the "center point"
> vertex, we can simply use any vertex on the perimeter. This should make
> the usual case of an aligned rectangle to collapse into two triangles
> instead of the current four, and work fine for all cases.
> And I still haven't gotten to the complex parts yet :-P
> - pq
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel