Talk:Nasal optimisation: Difference between revisions

Talk:Nasal optimisation (view source)

Revision as of 15:57, 5 December 2020

84 bytes added , 5 December 2020

m

→‎Partition processor

Hooray

Administrators

20,741

edits

Revision as of 15:56, 5 December 2020 (view source) Hooray (talk \| contribs) (→‎Partition processor: new section) ← Older edit		Revision as of 15:57, 5 December 2020 (view source) Hooray (talk \| contribs) m (→‎Partition processor) Newer edit →
Line 14:		Line 14:
	Do you have any plans for recursively registered/invoked partition processors (PP) In other words, such that each recursively invoked instance is aware of the outer instance and its constraints ? For instance, let's say the FG1000 gets a top-level partition processor instance, would it be possible to limit its impact o frame rate/spacing such that page-specific PP instances could sort of "inherit" settings from the outer/top-level instance ? The point being, there is the long-standing idea to hook up a PID instance to help manage FlightGear frame rate/spacing by using [[http://wiki.flightgear.org/Feature_Scaling]], e.g. referring to James comments at [http://sourceforge.net/p/flightgear/mailman/message/33057628/]		Do you have any plans for recursively registered/invoked partition processors (PP) In other words, such that each recursively invoked instance is aware of the outer instance and its constraints ? For instance, let's say the FG1000 gets a top-level partition processor instance, would it be possible to limit its impact o frame rate/spacing such that page-specific PP instances could sort of "inherit" settings from the outer/top-level instance ? The point being, there is the long-standing idea to hook up a PID instance to help manage FlightGear frame rate/spacing by using [[http://wiki.flightgear.org/Feature_Scaling]], e.g. referring to James comments at [http://sourceforge.net/p/flightgear/mailman/message/33057628/]

	The other issue being how the partition proessor deals with its job queue when new items arrive that may invalidate items still in the queue (imagine a MapStructure traffic layer still processing MP traffic when new positions arrive before the previous items are all processed)? Thank you. --[[User:Hooray\|Hooray]] ([[User talk:Hooray\|talk]]) 10:56, 5 December 2020 (EST)		The other issue being how the partition proessor deals with its job queue when new items arrive that may invalidate items still in the queue (imagine a MapStructure traffic layer still processing MP traffic when new positions arrive before the previous items are all processed)? Basicaly, this is asking how items in the PP queue are to be expired if necessary ? Thank you. --[[User:Hooray\|Hooray]] ([[User talk:Hooray\|talk]]) 10:56, 5 December 2020 (EST)