[Flightgear-devel] Observation about the Canvas Z-ordering

[James T. <zak...@ma...>]

Hi,

In trying to track down some issues with my remote-canvas code, I’ve realised something slightly surprising: the correct display of the canvas relies on an aspect (feature?) of the property code which is basically internal and hidden, namely the storage order of child nodes.

To explain, the Canvas elements have an optional Z-index, but in the absence of this, the creation order of elements is used. (Creation order becomes the storage order) Most Canvas code I’ve encountered so far is relying on this - child nodes are parsed in XML order, or from SVG which creates elements in SVG order. Usually no Z-indices are specified.

However, this order is not even exposed on SGPropertyNode (I’m about to have to add an API for exactly that, to fix my remote canvas issues). Nodes have a name + index, which is used widely of course, and we frequently query ‘all children called ‘input’’ and similar. But I can’t find anywhere besides the Canvas which depends on the child storage order/position. The property inspector sorts nodes by name+index before display, so the creation/positional order isn’t even visible by that means. Any other code which didn’t preserve positional order would break a Canvas (but I don’t know if we have any code like that)

If we had fewer extant users of Canvas, I would try to fix this (probably by requiring people to use Z-inded instead of rely on positional ordering) but I think we’re a way beyond that, so I shall expose the positional value on SGPropertyNode and replicate it to fix remote-canvas.

Kind regards,
James