KhronosGroup / KhronosGroup/KSCAF_DocGuidelines

Lost context (Bug 16134)

Open
#11 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
CSS
Stars
2
Forks
2
PR merge metrics
No merged PRs in 30d

Description

**Erik Noreke 2016-11-27 04:19:47 PST**

Background: In OpenGL SC there is a concept of "lost contexts". From my understanding this is an indeterminate state which cannot be further used and must be re-created. In between entering the lost context state and re-creating it I believe the front buffer of a window may still be asynchronously sampled from by a display. I believe this yield undefined content on display as for the OpenGL SC specification.

Despite not having much experience on OpenAL I believe a sound stream may have similar characteristics to a front buffer. I recall hearing one or two (non-SC) sound drivers making abnormal noises at maxed out volume for no good reason (honestly though I can´t be sure the audio library is to blame).

These are safety critical aspects because the state becomes undefined, which we already have concluded is not acceptable. Care should be taken defining the behavior as frozen output may be misleading depending on the content and API nature, whereas loss of (in the case of OpenGL i.e. black frame instead of last frame) may be worse depending on situation. Behavior that may startle an operator, e.g. pilot disturbed by flashing monitors or abnormal sound levels in headphones, is not acceptable!

My experience with OpenGL SC is that the display output is frozen during application or OS partition restart. Reading documentation I have yet to be convinced this is a defined behavior as of any specification.

Requirement: Upon error leading to a non-recoverable, non-usable state (e.g. "lost context") any external devices sampling from the state shall receive defined content from the state.
Note: It is a viable solution to stop external devices from sampling, although I suspect this may be difficult from the API itself depending on platform. Configurability of sampling behavior is not required but should be considered on writing specification based on API nature and target market.

**Comment 1 Erik Noreke 2016-11-27 04:20:24 PST**

Filed as guideline per discussion 2016/11/21.

**Comment 2 illya@codeplay.com 2016-11-28 00:52:23 PST**

Related to bugzilla 16059

**Comment 3 Erik Noreke 2016-12-12 07:18:51 PST**

Accepted per call 20161212.

Contributor guide

No contributing guide indexed for this repository

Research direction

Read the requirement and the reference to related bug 16059 first, then locate where this accepted guideline belongs in the project documentation. Done means specifying defined behavior for external devices sampling a non-recoverable state, including whether sampling stops or produces defined content.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.