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