ot tmpfs
and not memfd)?
Could it be that kwin is not doing partial texture uploads for some
reason and instead always uploads the full image?
I'd like to rule out the need to fix drivers, the compositor, or
clients first before buying into to adding proper buffer damage.
Adding buffer dam
surface damage cannot be used to decide what
> parts of the texture must be updated because it doesn't include the area
> of the buffer that got repaired. Either the client has to indicate the
> buffer damage or the compositor has to determine it by itself, e.g. by
> accumulati
buffer that got repaired. Either the client has to indicate the
buffer damage or the compositor has to determine it by itself, e.g. by
accumulating surface damages.
Hope this clarifies the things.
___
wayland-devel mailing list
wayland-devel@lists.freede
t; No, no, it was just an example when the surface damage and the buffer
> damage might be different, I don't necessarily want to optimize that
> extremely rare case. The issue is that the compositor has simply no idea
> how exactly the client utilizes the buffers. Keeping the last N sur
On 1/4/21 2:05 PM, Simon Ser wrote:
I don't think these would benefit from the optimization you're
suggesting. They don't cycle between pre-rendered buffers, for
instance.
No, no, it was just an example when the surface damage and the buffer
damage might be different, I don
On Monday, January 4th, 2021 at 1:00 PM, Vlad Zahorodnii
wrote:
> On 1/4/21 1:33 PM, Simon Ser wrote:
>
> > On Monday, January 4th, 2021 at 12:23 PM, Vlad Zahorodnii
> > vlad.zahorod...@kde.org wrote:
> >
> > Do you have real-world examples where the buffer damage
On 1/4/21 1:33 PM, Simon Ser wrote:
On Monday, January 4th, 2021 at 12:23 PM, Vlad Zahorodnii
wrote:
Do you have real-world examples where the buffer damage would improve
performance?
Buffer damage is needed once the compositor no longer attaches shared
memory client buffers to a single
On Monday, January 4th, 2021 at 12:23 PM, Vlad Zahorodnii
wrote:
> The buffer damage and the surface damage are not the same and there is
> no strong connection between the two, for example, if the buffer
> damage is empty, it doesn't imply that the surface damage is also emp
there must be some way to indicate the buffer damage. At the moment, if
a client feeds the compositor with shared memory client buffers, all
those buffers will be attached to a single texture and therefore the
surface damage is sort of (but not really) equivalent to the buffer damage.
Pushed this one (changed the commit log to say --use-damage-buffer)
On 30/11/15 01:11 PM, Derek Foreman wrote:
> On 30/11/15 01:47 AM, Pekka Paalanen wrote:
>> On Fri, 27 Nov 2015 14:55:13 -0600
>> Derek Foreman wrote:
>>
>>> On 27/11/15 07:47 AM, Pekka Paalanen wrote:
On Wed, 18 Nov 2015 1
On 30/11/15 01:47 AM, Pekka Paalanen wrote:
> On Fri, 27 Nov 2015 14:55:13 -0600
> Derek Foreman wrote:
>
>> On 27/11/15 07:47 AM, Pekka Paalanen wrote:
>>> On Wed, 18 Nov 2015 16:32:34 -0600
>>> Derek Foreman wrote:
>>>
Add a new flag for testing damage in buffer co-ordinates
On Fri, 27 Nov 2015 14:55:13 -0600
Derek Foreman wrote:
> On 27/11/15 07:47 AM, Pekka Paalanen wrote:
> > On Wed, 18 Nov 2015 16:32:34 -0600
> > Derek Foreman wrote:
> >
> >> Add a new flag for testing damage in buffer co-ordinates
> >>
> >> Signed-off-by: Derek Foreman
> >> ---
> >> client
On 27/11/15 07:47 AM, Pekka Paalanen wrote:
> On Wed, 18 Nov 2015 16:32:34 -0600
> Derek Foreman wrote:
>
>> Add a new flag for testing damage in buffer co-ordinates
>>
>> Signed-off-by: Derek Foreman
>> ---
>> clients/simple-damage.c | 62
>> +
>
On Wed, 18 Nov 2015 16:32:34 -0600
Derek Foreman wrote:
> Add a new flag for testing damage in buffer co-ordinates
>
> Signed-off-by: Derek Foreman
> ---
> clients/simple-damage.c | 62
> +
> 1 file changed, 47 insertions(+), 15 deletions(-)
>
On 18/11/15 07:24 PM, Bill Spitzak wrote:
> As this code is going to be referred to by people trying to figure out
> wayland, it might be best to use this by default. Fall back to the old
> damage request only if the api is too old or if a special switch is passed.
I agree, but I'll wait for addit
As this code is going to be referred to by people trying to figure out
wayland, it might be best to use this by default. Fall back to the old
damage request only if the api is too old or if a special switch is passed.
On Wed, Nov 18, 2015 at 2:32 PM, Derek Foreman
wrote:
> Add a new flag for te
Add a new flag for testing damage in buffer co-ordinates
Signed-off-by: Derek Foreman
---
clients/simple-damage.c | 62 +
1 file changed, 47 insertions(+), 15 deletions(-)
diff --git a/clients/simple-damage.c b/clients/simple-damage.c
index 0551b9
On Fri, Nov 16, 2012 at 05:50:38PM +0200, Ander Conselvan de Oliveira wrote:
> On 11/16/2012 05:37 PM, Pekka Paalanen wrote:
> >On Fri, 16 Nov 2012 17:23:52 +0200
> >Ander Conselvan de Oliveira
> >wrote:
> >
> >>Move fields current_buffer and buffer_damage out of weston_output into
> >>gl_output_s
On 11/16/2012 05:37 PM, Pekka Paalanen wrote:
On Fri, 16 Nov 2012 17:23:52 +0200
Ander Conselvan de Oliveira
wrote:
Move fields current_buffer and buffer_damage out of weston_output into
gl_output_state, since they are actually specific to the renderer.
Also bring back the previous_damage fie
On Fri, 16 Nov 2012 17:23:52 +0200
Ander Conselvan de Oliveira
wrote:
> Move fields current_buffer and buffer_damage out of weston_output into
> gl_output_state, since they are actually specific to the renderer.
>
> Also bring back the previous_damage field so that the screenshooter
> can get th
c v[2];
- /* When recording, this will be exactly the region that was repainted
-* in this frame. Since overlays are disabled, the whole primary plane
-* damage is rendered. For the first frame, the whole output will be
-* damaged and that damage will be added to both buff
{
@@ -270,9 +270,18 @@ weston_recorder_frame_notify(struct wl_listener *listener,
void *data)
} header;
struct iovec v[2];
+ /* When recording, this will be exactly the region that was repainted
+* in this frame. Since overlays are disabled, the whole primary plane
+
= 1;
> +
> }
>
> static void
> diff --git a/src/screenshooter.c b/src/screenshooter.c
> index ba80ce5..ffcc970 100644
> --- a/src/screenshooter.c
> +++ b/src/screenshooter.c
> @@ -261,7 +261,7 @@ weston_recorder_frame_notify(struct wl_listener
> *listener, void *data)
&
iovec v[2];
+ /* When recording, this will be exactly the region that was repainted
+* in this frame. Since overlays are disabled, the whole primary plane
+* damage is rendered. For the first frame, the whole output will be
+* damaged and that damage will
24 matches
Mail list logo
