Skip to content

Slight redesign of the raw framebuffer interface #62

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

Merged
merged 2 commits into from
Oct 14, 2018

Conversation

HadrienG2
Copy link
Contributor

@HadrienG2 HadrienG2 commented Oct 13, 2018

Here is a different take on the direct framebuffer interface:

  • A low-level (pointer, length) pair is returned instead of a high-level slice, since providing a slice gives the user the wrong impression that non-volatile writes are okay.
  • The unsafety barrier is shifted from the GOP to its client. After all, GraphicsOutput::framebuffer() is perfectly safe per se in the sense that there is no incorrect input or wrong call circumstance that will cause it to do unsafe things. It is the caller who is going unsafe by writing into the framebuffer after that.

Longer-term, the interface could be improved further by providing a more ergonomic way to do volatile writes (which would feel closer to the original slice abstraction).

@GabrielMajeri GabrielMajeri merged commit c2c1bb8 into master Oct 14, 2018
@HadrienG2 HadrienG2 deleted the framebuffer-review branch October 14, 2018 08:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants