-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
linux embedded
This feature request is primarily (only?) for Embedded use.
Currently when launching an application in embedded space, several lengthy command line arguments are required, setting system properties that toggle platform specific behavior. These toggles are in glass and jogl currently. It would make sense for these platforms to provide something like a resource file that could be used to trigger these behaviors, a resource file that would be installed as part of the target bundle. These platforms tend not to be easy to detect what settings are needed.
current example for canmore:
-Djogl.gldrawablefactory.class.name=com.sun.prism.opengl.impl.embedded.EmbeddedDrawableFactory \
-Dglass.platform=Embedded \
-Dprism.device=true \
-Dprism.order=es2 \
-Dprism.noFallback=true \
I have experimented with setting system properties in a couple of places, but at least one of the settings which affects jogl must be done prior to the pipeline creation. This would seem to require the values be set in Quantum in the initialization of the toolkit.
The straw man proposal for this feature would be to add a check in QuantumToolkit.init() for a resource bundle, and then set system properties as needed. I would continue to use system properties as the toggles as that seems the cleanest way of maintaining the separation of the modules. This needs to be done before the pipeline is created in init().
An alternate more targeted approach might be to query glass in QuantumToolkit.init() , which would query values out of the mat native library, which would allow the setting of a value that jogl would see.
Currently when launching an application in embedded space, several lengthy command line arguments are required, setting system properties that toggle platform specific behavior. These toggles are in glass and jogl currently. It would make sense for these platforms to provide something like a resource file that could be used to trigger these behaviors, a resource file that would be installed as part of the target bundle. These platforms tend not to be easy to detect what settings are needed.
current example for canmore:
-Djogl.gldrawablefactory.class.name=com.sun.prism.opengl.impl.embedded.EmbeddedDrawableFactory \
-Dglass.platform=Embedded \
-Dprism.device=true \
-Dprism.order=es2 \
-Dprism.noFallback=true \
I have experimented with setting system properties in a couple of places, but at least one of the settings which affects jogl must be done prior to the pipeline creation. This would seem to require the values be set in Quantum in the initialization of the toolkit.
The straw man proposal for this feature would be to add a check in QuantumToolkit.init() for a resource bundle, and then set system properties as needed. I would continue to use system properties as the toggles as that seems the cleanest way of maintaining the separation of the modules. This needs to be done before the pipeline is created in init().
An alternate more targeted approach might be to query glass in QuantumToolkit.init() , which would query values out of the mat native library, which would allow the setting of a value that jogl would see.