On Mon, 16 Nov 2015 10:19:39 +
Daniel Stone wrote:
> Hi,
>
> On 14 November 2015 at 07:55, Jason Ekstrand wrote:
> > On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote:
> >> Interesting problem just occurred to me... I don't think just not
> >> mixing damage/buffer_damage within a commit is
Hi,
On 14 November 2015 at 07:55, Jason Ekstrand wrote:
> On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote:
>> Interesting problem just occurred to me... I don't think just not
>> mixing damage/buffer_damage within a commit is good enough.
>>
>> What if a client commits faster than the screen re
On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote:
>
> On 13/11/15 02:03 AM, Pekka Paalanen wrote:
> > On Thu, 12 Nov 2015 13:48:10 -0600
> > Derek Foreman wrote:
> >
> >> On 12/11/15 01:27 PM, Jason Ekstrand wrote:
> >>> Thanks for picking this up! Also, thanks for posting this on the bug,
> >>>
On 13/11/15 02:03 AM, Pekka Paalanen wrote:
> On Thu, 12 Nov 2015 13:48:10 -0600
> Derek Foreman wrote:
>
>> On 12/11/15 01:27 PM, Jason Ekstrand wrote:
>>> Thanks for picking this up! Also, thanks for posting this on the bug,
>>> I would have missed it otherwise!
>>
>> Thanks to Pekka for prodd
On 13/11/15 02:03 AM, Pekka Paalanen wrote:
> On Thu, 12 Nov 2015 13:48:10 -0600
> Derek Foreman wrote:
>
>> On 12/11/15 01:27 PM, Jason Ekstrand wrote:
>>> Thanks for picking this up! Also, thanks for posting this on the bug,
>>> I would have missed it otherwise!
>>
>> Thanks to Pekka for prodd
On Thu, 12 Nov 2015 13:48:10 -0600
Derek Foreman wrote:
> On 12/11/15 01:27 PM, Jason Ekstrand wrote:
> > Thanks for picking this up! Also, thanks for posting this on the bug,
> > I would have missed it otherwise!
>
> Thanks to Pekka for prodding me to do so. :)
>
> > On Thu, Nov 12, 2015 at 1
On 12/11/15 01:27 PM, Jason Ekstrand wrote:
> Thanks for picking this up! Also, thanks for posting this on the bug,
> I would have missed it otherwise!
Thanks to Pekka for prodding me to do so. :)
> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman
> wrote:
>> On 09/11/15 09:06 AM, Pekka Paalane
Thanks for picking this up! Also, thanks for posting this on the bug,
I would have missed it otherwise!
On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman wrote:
> On 09/11/15 09:06 AM, Pekka Paalanen wrote:
>> On Fri, 6 Nov 2015 12:55:19 -0600
>> Derek Foreman wrote:
>>
>>> wl_surface.damage use
There seems to be some heated debate about whether we should deprecate
the old request or not, and how aggressively we should push people
towards the new one.
I've stayed out of that conversation, and think if we want to consider
that we can still do so after we land the new buffer_damage (now to
On 09/11/15 09:06 AM, Pekka Paalanen wrote:
> On Fri, 6 Nov 2015 12:55:19 -0600
> Derek Foreman wrote:
>
>> wl_surface.damage uses surface local co-ordinates.
>>
>> Buffer scale and buffer transforms came along, and EGL surfaces
>> have no understanding of them.
>>
>> Theoretically, clients pass
On Mon, Nov 9, 2015 at 11:47 PM, Pekka Paalanen wrote:
> On Mon, 9 Nov 2015 10:28:13 -0800
> Bill Spitzak 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 buff
On Mon, 9 Nov 2015 10:28:13 -0800
Bill Spitzak 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
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 transf
On Fri, 6 Nov 2015 12:55:19 -0600
Derek Foreman wrote:
> wl_surface.damage uses surface local co-ordinates.
>
> Buffer scale and buffer transforms came along, and EGL surfaces
> have no understanding of them.
>
> Theoretically, clients pass damage rectangles - in Y-inverted surface
> co-ordina
On Sat, 7 Nov 2015 09:49:21 -0800
"Jasper St. Pierre" wrote:
> So we fix the bug by adding wl_surface.buffer_damage, since it's
> impossible for Mesa to know about buffer transformations... and then
> what?
Be happy.
> The only way we can properly interpret the wl_surface.damage event is
> it b
Hi,
On 7 November 2015 at 17:49, Jasper St. Pierre wrote:
> OK. So the bug *wasn't* fixed two years ago like you were saying, and
> under transformations, mesa is still wrong.
It was fixed two years ago for clients using plain eglSwapBuffers,
which I posit is functionally equivalent to all of th
OK. So the bug *wasn't* fixed two years ago like you were saying, and
under transformations, mesa is still wrong.
So we fix the bug by adding wl_surface.buffer_damage, since it's
impossible for Mesa to know about buffer transformations... and then
what?
The only way we can properly interpret the
Hi,
On 7 November 2015 at 16:59, Jasper St. Pierre wrote:
> I don't see where. I see eglSwapBuffersWithDamage still looking like
> it shoves the rects across the wire in buffer space, without any
> modification.
>
> http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.
I don't see where. I see eglSwapBuffersWithDamage still looking like
it shoves the rects across the wire in buffer space, without any
modification.
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c#n705
I checked the Mali driver implementation I have, and it does
On 6 November 2015 at 19:08, Jasper St. Pierre wrote:
> To help clear things up, I think we should deprecate the
> wl_surface.damage request and document that the coordinates are
> effectively undefined -- for legacy reasons, if you see
> wl_surface.damage, it should be considered a damage for the
The description for wl_surface.damage should be shortened to a minimal
indication that this is for back-compatibility only and that refer to the
buffer_damage request. Something like "identical to buffer_damage if the
buffer and surface coordinates are equal, otherwise the behaviour is
undefined".
To help clear things up, I think we should deprecate the
wl_surface.damage request and document that the coordinates are
effectively undefined -- for legacy reasons, if you see
wl_surface.damage, it should be considered a damage for the entire
surface.
On Fri, Nov 6, 2015 at 10:55 AM, Derek Forema
wl_surface.damage uses surface local co-ordinates.
Buffer scale and buffer transforms came along, and EGL surfaces
have no understanding of them.
Theoretically, clients pass damage rectangles - in Y-inverted surface
co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation
passed them
23 matches
Mail list logo
