search

cpp-io2d / P0267_RefImpl

Reference Implementations of P0267, the proposed 2D graphics API for ISO C++
Other
313 stars 115 forks source link

Consider adding additional formats #13

Closed mikebmcl closed 7 years ago

mikebmcl commented 10 years ago

From Bengt Gustaffson: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/IaaG316uPjo/p-DoZqnLMwQJ

The format enum is currently a bit sparse. We should consider adding additional formats for pixel data beyond the handful that exist in the format enum. The suggestion links this with issue #12 (it's given a separate listing here because I think it's worth considering regardless of how issue #12 is decided).

mikebmcl commented 10 years ago

(Note: The example given is 3x12 RGB (12 bits per channel); I think the intention was probably R11G11B10. I'm not aware of any 36-bit formats in widespread usage. But it's entirely possible that they exist in a domain outside of my area of knowledge, such as high-end HDR photography or in some newest GPUs (and then likely only as an OpenGL extension since it hasn't made it's way into DXGI as of 11.2).

I caution that some formats are covered by patents. I'm thinking particularly of the S3TC formats a/k/a Dxt{1,3,5} a/k/a BC{1,2,3}. If we can get a grant from the patent holder that complies with the ISO Patent Policy (I would probably start by reaching out to someone at HTC, since S3 Graphics is one of their subsidiaries) I definitely think those formats should be included if the decision is made to add more formats. They are ubiquitous in gaming.

I do personally support the idea of adding more formats, with the caveats that:

  1. We should strongly consider delineating "safe" formats that are most likely to be available on any device;
  2. We should decide what formats, if any, should be mandatory (explicitly excluding freestanding implementations if necessary, though I don't think it is); and,
  3. We should explicitly define whether a format request throws if the format unavailable or gives if the implementation chooses a nearest approximation.

Point 3 is particularly troublesome to me because, depending on the developer and the application, falling back might be perfectly acceptable or completely untenable. Perhaps a good solution would be to take an initializer list of preferred formats, in order of preference, and throw only if none are available. Would this work? Is there a better way that doesn't introduce a ton of hidden overhead (maybe with some template magic)?

OpenGL requires some formats and allows others to "transparently" fall-back to a different format. D3D/DXGI fails if the requested format isn't available. Perhaps the intersection of DXGI feature level 9.1 and OpenGL mandatory formats is the way to go.

jube commented 10 years ago

I like the way this question is handled in Go. A "color" is just something that can be converted to RGBA (with 32 bits for each channels), and an image is abstracted to a matrix of color (even if the underlying format may be anything).

mikebmcl commented 7 years ago

This is now an open issue against the proposal itself - https://github.com/mikebmcl/io2dts/issues/23 . The a1 format is definitely going away in P0267R5. Other formats are likely to be added. I'm strongly considering switching from doubles to floats, but haven't decided for sure yet. Regardless, I'm closing this issue since it's a design issue and I'm making all design issues that are still unresolved io2dts issues.