20,741
edits
m (→Canvas.Path (OpenVG): https://sourceforge.net/p/flightgear/mailman/message/37605758/) |
|||
Line 272: | Line 272: | ||
=== Canvas.Path (OpenVG) === | === Canvas.Path (OpenVG) === | ||
{{WIP}} | |||
Will likely need to replace shiva vg with an OpenGL 2.0 based implementation like nanovg <ref>https://github.com/memononen/nanovg</ref>. | Will likely need to replace shiva vg with an OpenGL 2.0 based implementation like nanovg <ref>https://github.com/memononen/nanovg</ref>. | ||
From a quick eyeball just now, the code in CanvasPath.cxx looks /mostly/ to me: | |||
* all setXYZ methods set a dirty flag | |||
* there is an OSG updateCallback which updates the custom drawable | |||
* drawImplementation calls the rendering commands, with some extra work to synchronise the current OSG state with the Shiva use of state. | |||
Importantly, the vgPath is created inside update, but this /should/ only touch CPU state. Whereas if the attributes are dirty for say fill or colour or opacity, the vgPaint is re-created, and this likely touches OpenGL commands inside Shiva, so it’s done inside drawImplementation. | |||
So, I don’t see anything grossly incorrect here, with my understanding of what OSG expects, and what Shiva does. Importantly, I don’t see anything special related to culling at all. My recollection is that even in the most aggressive threading modes, OSG won’t update a node at the same time as drawing it, which is why there’s no internal locking: if this guarantee did not hold, I think almost every OSG Group/Node would need to internally lock its state, with enormous overhead. | |||
(There is a complication here around STATIC vs DYNAMIC nodes, but the Path node is tagged DYNAMIC, so the above guarantee should still be correct)<ref>https://sourceforge.net/p/flightgear/mailman/message/37605758/</ref> | |||
== Community talks == | == Community talks == |