Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enumerator style API for DisplayConfig #30

Open
JeroMiya opened this issue Sep 29, 2015 · 3 comments
Open

Enumerator style API for DisplayConfig #30

JeroMiya opened this issue Sep 29, 2015 · 3 comments

Comments

@JeroMiya
Copy link
Contributor

The C++ wrappers for the display config API let you enumerate the viewers, eyes, surfaces, and display input objects in a more natural way than the current managed bindings, which are flatter and closer to the C API.

Look into creating Viewer, Eye, Surface, and DisplayInput objects, and all of the associated methods for each, as well as the IEnumerable returning methods. This would make the API much easier and clean to use.

Once this is done, tag the "flat" API methods as [Obsolete] for now. They can be removed sometime before the first 1.0 release, once the Unity code is updated to use them.

@rpavlik
Copy link
Member

rpavlik commented Sep 30, 2015

:) this would be swell. the flat model is both useful (don't have to allocate memory or sling pointers around too much) but also a pain (those are some nearly-unmanageable function names).

@JeroMiya
Copy link
Contributor Author

If I'm careful about figuring out which bits are static for the lifetime of the DisplayConfig and which bits can change, I may be able to cache some of the objects created in order to eliminate new allocations in most cases. Not sure what pieces can change - I'd have to review the docs again.

@rpavlik
Copy link
Member

rpavlik commented Oct 1, 2015

Should hopefully be clear from the docs, but the topology of objects itself is constant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants