ProcDamageCreate emits a damage event - why?

[Ville Syrjälä]

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ä