Also, I think that MirBufferStream shouldn't go away. It fits a need that the clients have (as well as being used extensively in the wild).
Made some design drawings: A) How things are in current design: https://docs.google.com/drawings/d/1U03QrxQwPFYVfryC_-xOb64D3GRYIkJCAyw8LEWbbIk
B) how things would be with mir_presentation_chain_get_egl_native_window_type(...): https://docs.google.com/drawings/d/1cX54j6Wv7TRuWLCXRuUyni9RgyuljWGEAlalDirwAys
C) How things would be with mir_create_egl_native_window_type(...): https://docs.google.com/drawings/d/1yze9GbDb4pbGyQM7pXPDWXqrToW9Ko3gaAtWt9DeV_Q
A) and C) keep the MirPresentationChain just a thin wrapper around the RPC (which is useful for building future technologies). IMO, A) is a bit better because we only have one way of supporting EGL.
« Back to merge proposal
Also, I think that MirBufferStream shouldn't go away. It fits a need that the clients have (as well as being used extensively in the wild).
Made some design drawings: /docs.google. com/drawings/ d/1U03QrxQwPFYV fryC_-xOb64D3GR YIkJCAyw8LEWbbI k
A) How things are in current design:
https:/
B) how things would be with mir_presentatio n_chain_ get_egl_ native_ window_ type(.. .): /docs.google. com/drawings/ d/1cX54j6Wv7TRu WLCXRuUyni9Rgyu ljWGEAlalDirwAy s
https:/
C) How things would be with mir_create_ egl_native_ window_ type(.. .): /docs.google. com/drawings/ d/1yze9GbDb4pbG yQM7pXPDWXqrToW 9Ko3gaAtWt9DeV_ Q
https:/
A) and C) keep the MirPresentation Chain just a thin wrapper around the RPC (which is useful for building future technologies). IMO, A) is a bit better because we only have one way of supporting EGL.