Fwd: Best practices for client side buffer management

(Resending to the list) Hi Brad, El vie., 19 jun. 2020 a las 5:24, Brad Robinson () escribió: [...] > > Finally, the toolkit already maintains an off-screen buffer with the window's > current contents rendered into it. I'll probably replace that with a Wayland > buffer, but wondering about

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 19:17:57 +1000 Brad Robinson wrote: > Hi All, > > @Guillermo: yep, that's exactly the same problem I'm thinking about. Hi, I answered to Guillermo as well further down. > I had an idea that I'm wondering about the rendering model in my > toolkit is essentially the

Re: Best practices for client side buffer management

Hi Pekka, The problem is, the compositor might not release the buffer until > you have already submitted a new one. > OK... good to know that approach won't work. I guess what I'm trying to figure out (and probably won't solve completely till I actually sit down and code it) is how to avoid the

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 14:28:18 +0300 Pekka Paalanen said: > On Wed, 24 Jun 2020 10:58:41 +0100 > Carsten Haitzler (The Rasterman) wrote: > > > you keep a sliding window of the last 2 frames with of rect regions you > > union (merge with) the current frame's update rects... then render that. > >

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 10:58:41 +0100 Carsten Haitzler (The Rasterman) wrote: > you keep a sliding window of the last 2 frames with of rect regions you union > (merge with) the current frame's update rects... then render that. you can > play > tricks like copy back some regions from a previous

Re: Best practices for client side buffer management

On 2020-06-24 13:14, Pekka Paalanen wrote: On Wed, 24 Jun 2020 19:17:57 +1000 Brad Robinson wrote: Hi All, @Guillermo: yep, that's exactly the same problem I'm thinking about. Hi, I answered to Guillermo as well further down. I had an idea that I'm wondering about the rendering

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 13:35:12 +0200 Sebastian Wick wrote: > On 2020-06-24 13:14, Pekka Paalanen wrote: > > On Wed, 24 Jun 2020 19:17:57 +1000 > > Brad Robinson wrote: > > > >> 1. the compositor doesn't change the contents of the buffer and that > >> when > >> it's returned it's still got

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 19:17:57 +1000 Brad Robinson said: EFL has the same model - it tracks damage rects (either sent by expose/damage events from windowing system combined with a set of rect regions it calculates itself based on previous frame state vs current frame state and which

Re: Best practices for client side buffer management

Hi All, @Guillermo: yep, that's exactly the same problem I'm thinking about. I had an idea that I'm wondering about the rendering model in my toolkit is essentially the same as Windows/OSX - where the application invalidates part of the window, and then at some later point the OS calls back

Re: Best practices for client side buffer management

On Wed, 24 Jun 2020 23:45:56 +1000 Brad Robinson wrote: > Hi Pekka, > > > The problem is, the compositor might not release the buffer until > > you have already submitted a new one. > > > > OK... good to know that approach won't work. > > I guess what I'm trying to figure out (and probably

Current state of Window Decorations

Hey All, What's the current state and/or plans for window decorations with Wayland? I just stumbled on this post , and after reading the comments I've got to say I'm quite shocked that getting a window to appear