Re: ProcDamageCreate emits a damage event - why?
On 24.03.2011 02:25, Keith Packard wrote: That's icky. Fixing that without losing the damage sent to new clients might be tricky though. How about not using the existing machinery for sending the initial event? I imagine it would not be many lines of code for that situation. Possibly just calling pDamage->damageReport. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: ProcDamageCreate emits a damage event - why?
On Wed, 23 Mar 2011 18:11:48 +0200, Ville Syrjälä wrote: > There is at least one issue with the current implementation; It sends > the event to all clients who are interested in the same window. So > if you fire up your vnc screen scraper, your composite manager thinks > it has to redraw the window. I think that at least should be fixed. That's icky. Fixing that without losing the damage sent to new clients might be tricky though. -- keith.pack...@intel.com pgpIJaRYBMHSx.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: ProcDamageCreate emits a damage event - why?
On 3/23/11 12:11 PM, Ville Syrjälä wrote: There is at least one issue with the current implementation; It sends the event to all clients who are interested in the same window. So if you fire up your vnc screen scraper, your composite manager thinks it has to redraw the window. I think that at least should be fixed. Ew, right you are. That's definitely not intended behaviour. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: ProcDamageCreate emits a damage event - why?
On Wed, Mar 23, 2011 at 11:53:05AM -0400, ext Adam Jackson wrote: > On 3/23/11 7:24 AM, Erkki Seppala wrote: > > > So what kind of guessing are we talking about here? What is the downside > > of removing this initial damage event? The downside with the current > > code is that it can lead to some excess work when no damage has > > occurred. (I wonder if the behavior can changed, though, if some > > applications already depend on it.) > > I suspect that the guess, from the client's perspective, is about the > actual window geometry at the time the damage was created. > > I can easily imagine clients depending on this behaviour at this point, > since it means you don't need to manually do a "first run" of your > damage handler against the initial window state; you can just let your > event loop pick it up naturally. If you're a damage-based vnc screen > scraper, that's a feature. > > If you have an example where this does cause excess work, it'd be pretty > easy to extend the protocol so the damage level argument includes a bit > for (not) adding the initial clip. There is at least one issue with the current implementation; It sends the event to all clients who are interested in the same window. So if you fire up your vnc screen scraper, your composite manager thinks it has to redraw the window. I think that at least should be fixed. -- Ville Syrjälä ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: ProcDamageCreate emits a damage event - why?
On 3/23/11 7:24 AM, Erkki Seppala wrote: So what kind of guessing are we talking about here? What is the downside of removing this initial damage event? The downside with the current code is that it can lead to some excess work when no damage has occurred. (I wonder if the behavior can changed, though, if some applications already depend on it.) I suspect that the guess, from the client's perspective, is about the actual window geometry at the time the damage was created. I can easily imagine clients depending on this behaviour at this point, since it means you don't need to manually do a "first run" of your damage handler against the initial window state; you can just let your event loop pick it up naturally. If you're a damage-based vnc screen scraper, that's a feature. If you have an example where this does cause excess work, it'd be pretty easy to extend the protocol so the damage level argument includes a bit for (not) adding the initial clip. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
ProcDamageCreate emits a damage event - why?
Hello, I'm investigating an issue where applications receive damage events when they create a new damage object. The code in question is this: static int ProcDamageCreate (ClientPtr client) { .. if (pDrawable->type == DRAWABLE_WINDOW) { pRegion = &((WindowPtr) pDrawable)->borderClip; DamageDamageRegion(pDrawable, pRegion); } return Success; } and the relevant commit message for this 7-year old change by Keith at: http://webcvs.freedesktop.org/xserver/xserver/damageext/damageext.c?r1=1.4&r2=1.5&pathrev=MAIN is this: * damageext/damageext.c: (ProcDamageCreate): Add borderClip to damage on creation so that clients needn't guess. So what kind of guessing are we talking about here? What is the downside of removing this initial damage event? The downside with the current code is that it can lead to some excess work when no damage has occurred. (I wonder if the behavior can changed, though, if some applications already depend on it.) The documentation at http://cgit.freedesktop.org/xorg/proto/damageproto/plain/damageproto.txt is somewhat sparse.. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel