[PATCH wayland] protocol: Remove incorrect statement that attach must precede damage

[Derek Foreman]

On 19/11/15 12:25 PM, Bill Spitzak wrote:
> 
> 
> On Thu, Nov 19, 2015 at 3:08 AM, Daniel Stone <daniel at fooishbar.org
> <mailto:daniel at fooishbar.org>> wrote:
> 
>     Hi,
> 
>     On 18 November 2015 at 18:30, Bill Spitzak <spitzak at gmail.com
>     <mailto:spitzak at gmail.com>> wrote:
>     > On Wed, Nov 18, 2015 at 7:44 AM, Derek Foreman
>     <derekf at osg.samsung.com <mailto:derekf at osg.samsung.com>>
>     > wrote:
>     >> The documentation for wl_surface.commit makes it clear that the
>     >> application of damage follows attach during the commit, so it
>     >> doesn't matter what order the app sends the requests.
>     >>
>     >> Many existing apps post damage before attaching a buffer already,
>     >> and it's really quite reasonable to do so.
>     >
>     > Especially because they probably think of the old buffer as being
>     the one
>     > that is "damaged", while the new buffer does not have any damage.
> 
>     No, it does. The old buffer has not changed. The new buffer is the one
>     with the changed areas, and changed areas are the literal definition
>     of damaged.
> 
> 
> Actually neither buffer has changed. The damage is saying that only the
> pixels in the rectangle are different between the old and new buffer.
> 
> I was just saying that I can certainly think of people as saying "the
> old buffer is bad in this area, therefore I must send this message now
> to indicate it is bad. If I change the buffer first then this message is
> saying the new buffer is bad in this area, when in fact the new buffer
> is perfect". This is all incorrect but is likely the logic that caused
> almost all clients to send the damage request first.

Well, the most common use seems to be
wl_surface_damage(foo, 0, 0, INT32_MAX, INT32_MAX);

before attaching a buffer at all (perhaps before the client has *ever*
attached a buffer), to indicate the new buffer will be all new data.