20,741
edits
FlightGear and OpenGL Core Profile: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear and OpenGL Core Profile (view source)
Revision as of 14:06, 7 February 2022
, 7 February 2022→Canvas.Path (OpenVG)
m (→Canvas.Path (OpenVG): https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=30#p390529) |
|||
| Line 280: | Line 280: | ||
As part of the Core profile migration, we need to replace ShivaVG (which is the functional guts of Path.cxx) with a shader based implementation, ideally NanoVG, although Scott has indicated this might not be as easy as originally hoped. <ref>https://sourceforge.net/p/flightgear/mailman/message/37605458/</ref> | As part of the Core profile migration, we need to replace ShivaVG (which is the functional guts of Path.cxx) with a shader based implementation, ideally NanoVG, although Scott has indicated this might not be as easy as originally hoped. <ref>https://sourceforge.net/p/flightgear/mailman/message/37605458/</ref> | ||
Furthermore, there are segfaults/race conditions that are reportedly related to Canvas Path: Based on what we've seen and discussed so far, I still think that it's primarily Canvas.Path (specifically ShivaVG) that we need to look at - aggressive OSG threading is ... aggressive. | Furthermore, there are segfaults/race conditions that are reportedly related to Canvas Path: Based on what we've seen and discussed so far, I still think that it's primarily Canvas.Path (specifically ShivaVG) that we need to look at - aggressive OSG threading is ... aggressive. <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&hilit=path+osg+canvas&start=30#p390529</ref> | ||
Which is to say, the Canvas.Path element is not even using native OSG code, and the flickering shown in the screen shots, suggests that it's something related to Canvas.Path handling. | Which is to say, the Canvas.Path element is not even using native OSG code, and the flickering shown in the screen shots, suggests that it's something related to Canvas.Path handling. | ||
Inside a gdb session, you'll probably see something related to $SG_SRC/canvas/elements/shiva - which is where the 3rd party sources related to ShivaVG reside: | |||
<pre> | |||
https://github.com/ileben/ShivaVG/blob/master/README | |||
No multi-threading support has been implemented yet. | |||
This also pointed out in the Qt 4 docs, when shiva was used: | |||
https://doc.qt.io/archives/qt-4.8/openvg.html | |||
The paint engine is not yet thread-safe, so it is not recommended for use in threaded Qt applications that draw from multiple threads. Drawing should be limited to the main GUI thread. | |||
</pre> | |||
i.e. the shiva stuff is called by C++ code from multiple threads - otherwise, seeing flickering specific to map elements implemented via OpenVG (Canvas.Path) would not make sense | |||
Shiva itself cannot be considered thread-safe, but may be invoked from multiple threads in fgfs, once fgfs is being used in conjunction with compositeviewer: | |||
So far however everything points at canvas, and looking at canvas code, it seems that there's a lot of stuff going on in update and | So far however everything points at canvas, and looking at canvas code, it seems that there's a lot of stuff going on in update and | ||