Improve weston_surface and weston_view identification for debugging
When debug prints need to identify a
weston_surface or a
weston_view, they print the raw pointer with
%p. 64-bit pointers are hard to read for humans, and even harder to compare for correlating debug messages. These pointers should be replaced with more human-friendly IDs.
uint32_t counter in
struct weston_compositor for generating such IDs, store them in
weston_view, and use them in debug prints.
Pointer values may get re-used if the struct is freed and then another is allocated at the same address. OTOH,
uint32_t may wrap around, but I suspect that is rare enough to not be a concern. If it proves to be a concern, we can easily upgrade to 64-bit, but then again the point of having it for human-readability is lost anyway.
Also better ideas for making it easier to identify surfaces and views are welcome. Note, that Wayland protocol object IDs are not unique in a
weston_compositor, they are only unique for a client and they get aggressively re-used.
We could also consider a string naming scheme, e.g.
<client-id>:<item-id>:<protocol-object-id> where client-id would be zero for items that were not associated with any client when allocated, item-id would come from a per-client counter, and protocol-object-id comes from the corresponding Wayland protocol object ID if there is any (e.g.
wl_surface ID for
weston_view). This would be different from the description string we already have for
weston_surface. This could be stored as a string in the item.