<div dir="ltr">Allow me to chip in here.  Sorry that I haven't had a chance to really look over things carefully.  I have been reading this thread, just haven't had a chance to respond.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 12:41 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 30 Sep 2014 14:35:24 -0500<br>
Derek Foreman <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote:<br>
<br>
> Thanks for taking a look!<br>
><br>
> On 26/09/14 05:48 PM, Bill Spitzak wrote:<br>
> > 90 degree rotation about x or y will require filtering.<br>
><br>
> Yup, you're right.<br>
><br>
> > You test y scale twice, must be a typo. I think you intended to test z,<br>
> > but in fact z scale is not relevant so you should not test it at all.<br>
><br>
> Argh - thanks.  Why isn't Z scale relevant?  I'm worried about making<br>
> assumptions about the transformations these matrices represent and<br>
> having those assumptions violated in the future...  For Z not to matter<br>
> are we assuming projection will always be orthographic?<br>
<br>
</span>Weston never uses the final Z coordinate for anything, so in that sense<br>
it is always orthographic. Essentially, we could just do with 3x3<br>
matrices perfectly fine. 3x3 supports 2D-projective which is enough to<br>
implement fake-3D effects like<br>
<a href="http://people.collabora.com/~pq/rotate3d-fun.webm" target="_blank">http://people.collabora.com/~pq/rotate3d-fun.webm</a><br>
(The gl-renderer does not route the W element at all, I had to patch<br>
that. Pixman-renderer OTOH just worked.)<br>
<br>
Weston also hardcodes the input Z coordinate always to 0, no matter<br>
which way you are going between buffer and output spaces.<br>
<br>
I suppose the 4x4 matrix was originally chosen to fit the OpenGL API.<br>
And maybe with some speculation about a desktop cube implementation or<br>
something, but I don't really see the cube or such coming, not as a<br>
generic thing anyway as only the gl-renderer could support it with<br>
true 3D space.<br>
<span class=""><br>
> > Translation by non-integer will also require filtering.<br>
><br>
> Good point.<br>
><br>
> > I recommend instead of checking the rotation to instead look for zeros<br>
> > in the correct locations in the matrix. Matrix must be of the form:<br>
> ><br>
> >  |sx 0  0 tx|<br>
> >  |0  sy 0 ty|<br>
> >  |?  ?  ?  ?|<br>
> >  |0  0  0  1|<br>
> ><br>
> > or<br>
> ><br>
> >  |0  sx 0 tx|<br>
> >  |sy 0  0 ty|<br>
> >  |?  ?  ?  ?|<br>
> >  |0  0  0  1|<br>
> ><br>
> > sx and sy must be ±1, and tx and ty must be integers. The ? can be any<br>
> > value.<br>
><br>
> That could save us the very expensive matrix decomposition.  I'll try<br>
> this out.  Thanks.<br>
><br>
> I think this may be better than decomposition for deciding to use video<br>
> planes in compositor-drm as well.<br>
><br>
> (In fact, you've got me wondering if we ever need to split a matrix into<br>
> basic transformations at all...)<br>
<br>
</span>I'd be wondering about that, too. My intuition would say there is no<br>
need to really decompose. Just checking the elements should suffice,<br>
and when the matrix is supportable for whatever, then you pick the<br>
right elements (which is a bit like decomposition, but no need to be<br>
generic at all).<br></blockquote><div><br></div><div>Yeah, I'm not convinced we need to be able to do a full decomposition either.  My original intention was something like this:<br><br></div><div>bool<br></div><div>weston_matrix_to_integer_transform(const weston_matrix *mat, enum wl_output_transform& transform, int *scale, int *x, int *y)<br><br></div><div>(do we use "bool" in weston?  Maybe just return int).  We may need both x and y scales and it may be useful to get those as floats.  I'm not sure on that.  Pekka, what would the RPi backend use?  Basically, we want to be able to do 2 things: First, detect if it's an entirely integer transform and use GL_NEAREST instead of GL_LINEAR and second, know how to flip the surface around in cases when we can do some simple transformations but can't do an arbitrary matrix transformation.  One example here is DRM planes.  We can only use a plane when there's no scale and the buffer-to-output transform has no rotation.  We need to check for that condition and then pull the needed data out.<br><br>Point is, we don't need a full matrix decomposition.  Also, it's worth throwing out there that the caching probably doesn't help us at all because we're going to usually be calling this on freshly computed matrices such as the above mentioned buffer-to-output transform.<br><br>Does that make sense?<br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And you take take advantage of the fact that incoming Z=0 and outgoing<br>
Z is ignored, I believe. That is, for the final, total transformation<br>
matrix between buffer and output spaces.<br></blockquote><div><br></div><div>Yes, we can vastly simplify things by taking that into account.  Basically, you can throw away the 2nd row and column and not care about them at all.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > Also pixman is already doing equivalent tests and short-circuiting to<br>
> > nearest filter, so you might not need to check this anyway.<br>
><br>
> This is also used for the gl renderer, so I don't think I can count on<br>
> that short circuit there...  Though bilinear vs nearest doesn't have<br>
> anywhere near the same performance impact there.<br>
<br>
</span>Yeah, we need to pick nearest vs. linear in the gl-renderer ourselves.<br>
Even if the choice did not affect the outcome, choosing nearest when we<br>
can might save memory bandwidth. I hope.<br>
<br>
And then we have the accuracy problems of GL, so picking nearest<br>
guarantees a crisp image reproduction, otherwise one might get a little<br>
blur. In theory we should get rid of the blur by careful coordinate<br>
manipulation even with linear, but I'm not sure that manipulation is<br>
portable between GL implementations.<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class="HOEnZb"><div class="h5"><br>
> Are you suggesting pixman always be set to use bilinear, and it'll just<br>
> pick nearest automatically when the image transform doesn't require it?<br>
><br>
> > On 09/26/2014 02:10 PM, Derek Foreman wrote:<br>
> ><br>
> >> +WL_EXPORT int<br>
> >> +weston_matrix_needs_filtering(struct weston_matrix *matrix)<br>
> >> +{<br>
> >> +    if (!rot_is_90(weston_matrix_get_rotation_x(matrix))<br>
> >> +     || !rot_is_90(weston_matrix_get_rotation_y(matrix))<br>
> >> +     || !rot_is_90(weston_matrix_get_rotation_z(matrix))<br>
> >> +     || (fabs(weston_matrix_get_scale_x(matrix) - 1.0) > 0.0001)<br>
> >> +     || (fabs(weston_matrix_get_scale_y(matrix) - 1.0) > 0.0001)<br>
> >> +     || (fabs(weston_matrix_get_scale_y(matrix) - 1.0) > 0.0001))<br>
> >> +        return 1;<br>
> >> +<br>
> >> +    return 0;<br>
> >> +}<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div>