Re: XCB_DESTROY_NOTIFY & SIGTERM

Uli Schlachter <[email protected]> Wed, 4 Dec 2024 20:21:45 +0100
Newsgroups gmane.comp.freedesktop.xcb
Message-ID <[email protected]>
Hi,

Am 04.12.24 um 20:00 schrieb Steven J Abner:
> On Wed, Dec 4 2024 at 05:32:06 PM +0000, Uli Schlachter <[email protected]=
>=20
> wrote:
>> How come you only get XCB_DESTROY_NOTIFY for your window? Normally,=20
>> one uses the WM_DELETE_WINDOW to get a notification and destroy the=20
>> window oneself. That way, you can clean up your cairo resources before=
=20
>> the window is gone.
>=20
> On WM_DELETE_WINDOW:
>  =C2=A0/* check transients, appropriate branch */
> xcb_unmap_window(connection, window);
>  =C2=A0/* user save stuff, non-transient */
> xcb_destroy_window(connection, window);
> xcb_flush(connection);
> which yields a XCB_DESTROY_NOTIFY at which point:
> free/destroy data that was attached to destroy->window (event), from li=
st.
>=20
> But what you are implying is that cairo is wrong in that "The caller=20
> owns the surface and should call cairo_surface_destroy() when done with=
=20
> it.", and it's owned by xcb?
> Easy enuf to move after user save, I think?. Would create 2 locations=20
> for resource deletion. Maybe a cairo ownership issue? Insights, on cair=
o=20
> if any?

I am not sure about what you are implying with ownership, but (with my=20
cairo hat on), I would claim that you have to (at least)=20
cairo_surface_finish() before the drawable is destroyed. It might also=20
be possible to just flush it, but I would not count on it.

Uli

P.S.: cairo_surface_destroy() implicitly calls cairo_surface_finish()=20
when the reference count hits zero.
--=20
=E2=80=9CI=E2=80=99m Olaf and I like warm hugs.=E2=80=9D