Are there any unused created entities?

[safocl]

from line https://github.com/jaelpark/chamferwm/blob/master/src/compositor.cpp#L1465 to line https://github.com/jaelpark/chamferwm/blob/master/src/compositor.cpp#L1469 -- are the entities used?
xcb_shm_get_image_reply_t * is created but then only released without use.
Do we have to create these entities?

There are several such situations in your code.

[jaelpark]

I don't think lines 1465 to 1469 are in fact unnecessary, even though it might appear so. While the call to xcb_shm_get_image for example looks out of place, internally it (I presume) updates or syncs the buffers for external access. Earlier, I did try would it work without it, or if I moved it to somewhere else and called it maybe once, but the testing showed that it would only result in black buffers. I'm not aware of better usage when dealing with SHM though. What are the other occurrences where it would seem (or is definitely the case) some portion of code is not needed?

[safocl]

What are the other occurrences where it would seem (or is definitely the case) some portion of code is not needed?

in that file the lines 1485-1489.

[safocl]

I don't think lines 1465 to 1469 are in fact unnecessary, even though it might appear so. While the call to xcb_shm_get_image for example looks out of place, internally it (I presume) updates or syncs the buffers for external access. Earlier, I did try would it work without it, or if I moved it to somewhere else and called it maybe once, but the testing showed that it would only result in black buffers. I'm not aware of better usage when dealing with SHM though.

ok, but why creating pointer xcb_shm_get_image_reply_t *pimageReply?

[jaelpark]

In some cases the image depth is given by pimageReply, although not needed everywhere. However, elsewhere we're just getting the reply and then discarding it immediately after by freeing the memory. This just gave me an idea that I could try xcb_discard_reply instead of calling xcb_shm_get_image_reply. The problem might be that xcb_discard_reply is non-blocking, and the buffers may not yet be available for copying by the time it returns, so it might fail. But I will test it for sure, and if everything looks normal, I can make the changes.

[jaelpark]

Nope, it didn't work. While the window contents are visible, the frames are no longer synchronized. In the current design, xcb_shm_get_image_reply is needed to wait for the internal update to finish, and the returned pointer is needed to free the memory. I'll leave this open again for some time if there will be better ideas how to handle it.

[safocl]

I just think that *_reply is for data access only -- it does nothing about the internal Xorg structure.

[jaelpark]

It doesn't, but it allows one to wait for the internals to be ready for copying. If the next step i.e. access to the shared memory buffers is done without it, it seems to result in glitching and dropped frames.