FlightGear and OpenGL Core Profile: Difference between revisions

Jump to navigation Jump to search
m
→‎Canvas.Path (OpenVG): https://sourceforge.net/p/flightgear/mailman/message/37605758/
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 ==

Navigation menu