On Mon, 9 Nov 2015 10:28:13 -0800 Bill Spitzak <spit...@gmail.com> wrote:
> I believe wl_surface.damage should be defined as "the same as > w_surface.buffer_damage if the only transforms are due to an integer buffer > scale and the 8 possible buffer transforms". This means it is undefined if > the wl_scalar proposal is used, and avoids the need to define it for any > future transform possibilities. I have no idea how that could help with anything. It does not matter what the mapping is between surface and buffer coordinate systems: damage is in surface space, and buffer_damage is in buffer space. There is nothing ambiguous about that, even if someone added even more transformations between them. > For very similar reasons I believe the wl_scalar and the subsurface apis > will need to be changed to be in buffer coordinates. So a defined suffix > (such as _buffer or _pixels) is probably a good idea so these can be fixed > in a similar way. That leads to fractional "pixel" units inside a compositor, wl_viewport would then completely bypass buffer scale and transform (transform is not representable in wl_viewport), and I simply don't see the point at all. Please provide a real-world use case that would benefit from what you propose. Nothing that you "can imagine", but a real case that exists, just like eglSwapBuffersWithDamage is a real use case for buffer_damage. For example, showing that GStreamer will have problems using wl_viewport properly on a hidpi output would be valuable right now when the scaler extension is not yet stable. Mind, that you cannot show this unless you know how Gstreamer works. Speculation does not count. This is also off-topic for this thread, so please start a new one about the scaler extension. Thanks, pq
pgpIGjsT0vBd0.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
