02:21 ngortheone: kennylevinsen: if it is just the ID selected by the client - how come the client is forced to use new_id ==2 ?
02:49 ngortheone: So it is an implementation detail.
02:49 ngortheone: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-util.c#L282
02:50 ngortheone: clients are forced to select the lowest unoccupied ID
02:52 ngortheone: that is technically a violation of the spec, because clients are not free to choose any id, the server tracks their IDs. It might as well allocate IDs for them.
03:23 Arnavion: It's not an implementation detail
03:24 Arnavion: https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Creating-Objects >For efficiency purposes, the IDs are densely packed in the sense that the ID N will not be used until N-1 has been used. Any ID allocation algorithm that does not maintain this property is incompatible with the implementation in libwayland.
03:38 ngortheone:hmm
03:40 ngortheone: in this case I can still argue that server might as well allocate id's for the client. This optimizaion forces client to repeat the work of id tracking, the work that server is already doing..
03:41 ngortheone: "is incompatible with the implementation in libwayland" - implementation detail of libwayland :D
03:41 Arnavion: No
03:41 danieldg: well, having the client maintain an id freelist saves a round-trip compared to having the server allocate ids
03:41 Arnavion: The link I gave you is about the protocol. The first sentence is the protocol telling you to use sequential IDs. The second sentence is the protocol motivating you to listen to the first sentence, because if you don't you'll be incomatible with libwayland
03:42 Arnavion: If the HTTP protocol told you that requests start with "HTTP", and if you don't send "HTTP" you'll be incomatible with Apache, it wouldn't mean that requests starting with "HTTP" is an implementation detail of Apache
03:42 Arnavion: incompatible*
03:43 ngortheone: I see what you are saying, Arnavion. And you are probably right. I think the wording of the document could've been a bit more straightforward.
03:44 Arnavion: (Of course it's possible the libwayland implementation is the reason the protocol tells you to do that, but the point still stands that it's codified in the protocol now)
03:45 ngortheone: Thius is design choise is likely dictated by the fact that the fastest lookup algorithm is O(1) and it is array index operation. There is nothing faster than that.
03:48 ngortheone: Well behaving clients have to maintain a separate datastructure, like a (de)queue/heap to maintain the list of available indices (to re-use an index that was deleted in the middle of the array)
03:48 ngortheone: but there is nothing stopping a client to sequentially allocate IDs without re-using old indices
03:50 Arnavion: The sentence I posted does not require to reuse indices in the middle of the array, and the code you linked allows both an index in the middle of the array or an index at the end
03:51 ngortheone: Yes. that is why I'm saying "well-behaving clients should ..."
03:53 Arnavion: I don't see why one should be considered "well-behaving" and the other shouldn't
03:55 ngortheone: I can argue that well-behaving clients less waste server's memory by doing free index tracking
03:55 Arnavion: If the server wanted clients to not waste memory it wouldn't have set WL_MAP_MAX_OBJECTS to 15 million
03:57 ngortheone: yes, but it does not pre-allocate that much memory. Every once in a while an array with object id's has to be grown. And it means moving memory around (https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-util.c#L110)
03:57 Arnavion: Yes I'm aware. That doesn't change what I said
04:05 ngortheone: ok, this is debate is pointless and I sense some passive-agression. Thanks for your answers Arnavion. I will disengage now
04:05 Arnavion: You sense incorrectly.
09:48 wlb: wayland Merge request !311 opened by Mikhail Gusarov (dottedmag) doc: Improve wording for packed IDs https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/311
09:49 dottedmag: ^^ hopefully the confusion about implementation details will be cleared. I also was confused about it while reading the document for the first time
09:52 swick[m]: JoshuaAshton: I don't think that those are special requirements. We want our color management to work for the vfx industry and also need direct scanout for mobile devices.