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

How to sell gfx-rs #107

Closed
brendanzab opened this issue Jul 16, 2014 · 2 comments
Closed

How to sell gfx-rs #107

brendanzab opened this issue Jul 16, 2014 · 2 comments

Comments

@brendanzab
Copy link
Contributor

I'm just trying to think of as how a novice would see GFX. I mean the first though is, why use this over bare opengl or HGL? Might be a marketing question more then a technical question. - @csherratt


I'm very positive about the low-level interface that gfx-rs provides at the moment. We have a narrow but pretty definite scope, which gives a chance to produce a high quality library for that domain. A small piece to do its thing right - abstract the device, put it into its own thread, provide safe interface for drawing stuff. - @kvark


It's safe, it's bindless, it supports multiple backends to help support older architectures. It gives the user a mult-threaded render. - @csherratt

@kvark
Copy link
Member

kvark commented Aug 21, 2014

It's not difficult to hack a simple graphics app on a bare API like OpenGL. It is difficult to scale it both in size and onto other APIs. Typical issues:

  1. C API unsafety leading to undefined behavior or crashes. gfx-rs wraps it safely.
  2. API's are ... different. gfx-rs architecture is made for compatibility with modern graphics APIs, like Mantle, Metal, DX12, and GLNG.
  3. Leaking states due to either programmer errors or state caching bugs. gfx-rs is a bind-less API (!), where we can join forces to make sure the state caching under the hood is perfect.
  4. Illegal function calls and/or parameters. I.e. invalid buffer strides, element offsets, wrong glVertex_PointerCall function, wrong glUniform_ call, etc. For the hand-written vertices and programs, gfx-rs has #[vertex_format] and #[shader_param] macros that do wonders. For the loaded stuff, we can at least ensure proper function calls based on the data types.
  5. Mismatched states between different graphics systems. I.e. shader attribute locations/semantics versus actual data. gfx-rs enforces that to match.

All in all, gfx-rs tries to do all the dirty caching/matching/abstracting/safety wrapping work, while (ideally) not imposing any restrictions on what you want to do.

@kvark
Copy link
Member

kvark commented Feb 12, 2019

triaged: I think we can still improve our messaging in README

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

No branches or pull requests

2 participants