20,741
edits
Line 481: | Line 481: | ||
=== Property I/O observations === | === Property I/O observations === | ||
actual problem is property I/O - we can't read/write several hundreds of properties per frame without creating a bottleneck. So it's largely irrelevant how fast the Nasal code runs, whether it's parallel or whether it's Python-driven code running on the GPU - as long as property I/O speed doesn't change, performance will be stuck right there.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=296410#p296410 | |||
|title = <nowiki> Re: Nasal must go </nowiki> | |||
|author = <nowiki> Thorsten </nowiki> | |||
|date = Oct 9th, 2016 | |||
|added = Oct 9th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
The workload is certainly a function of the number of screens (canvas textures/FBOs) (unless you can assume have duplicate screens, in which case you can cut it by re-using a canvas or using a data provider). | The workload is certainly a function of the number of screens (canvas textures/FBOs) (unless you can assume have duplicate screens, in which case you can cut it by re-using a canvas or using a data provider). | ||
Creating the property structure by simply copying it turned out to be the largest drag in setting up a canvas display.<ref>{{cite web | Creating the property structure by simply copying it turned out to be the largest drag in setting up a canvas display.<ref>{{cite web |