objarni's picture

OpenTK API: When is it OK to favor elegance before optimal performance?

Following a recent debate in the thread about the new Half-datatype, I'm starting this thread to discuss the open/hard question of the balance of elegant API design vs performance.

For me the design of OpenTK should prefer elegant/easy to use/clean APIs before cumbersome APIs as long as the estimated effect of the performance gain using the cumbersome API is not noticeable in a typical OpenTK application.

Of course there are many vague concepts in that:

1) what is elegant? easy to use? clean?
2) what is cumbersome?
3) what is noticeable?
4) what is a typical OpenTK application?

Let me give my answers to these questions to give something to talk about:

1) what is elegant? easy to use? clean?
- A library that has a coherent design, for example using it's own Vector4/Matrix4 types in the other APIs.
- Methods with ref/out parameters are uglier than those without 'em
- Consistent naming of APIs/parameters etc.
- Operator overloads for ordinary maths types (vectors and matrices)
- Follows cultural practice of the language/environment in which it lives (.NET/C#)

2) what is cumbersome?
- ref/out/arrays/pointers in parameters to methods
- in general something that is not readable (eg. vectors/matrices could have a mathematical notation - something that is not possible in OpenTK because of the design choices made)

3) what is noticeable?
I'd say if a human being used to playing PC games cannot distinguish the "smoothness" of an application with/without an optimization, it is quite unnecessary.

4) what is a typical OpenTK application?
Hard one. But some typical apps' seem to be: 3d model viewers/editors, simple 3d games (no AAA game yet at least..), graphics driver in higher-level libraries (Agate lib eg.)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

[Side note: Would you consider "developer productivity" that is easy-to-deploy, easy-to-use and still fast enough for realtime 3d applications to be an accurate destillation of your three rules?]
Easy-to-use, easy-to-deploy and fast, that's about right. Also add portable (which is what differentiates us from e.g. SlimDX) and free somewhere to that list.

You are right, this would make a nice project statement. Anyone care to help refresh the frontpage? (relevant issue report)

Do you mean "usability" as in "possible applications/usage scenarios"? For me usability means ease-of-use.
Yes, I meant "usability" as in "potential uses".

Right now, I think the math library is the Achilles' heel of OpenTK. It's "inner loop" stuff and despite optimization we are still a far cry from native code. That's why Mono.SIMD is so interesting, it brings a potential 10x speed increase with little extra work. As a sidenote, there's talk about implementing a standardized Mono.Math library in the future, which would be awesome as it would allow diverse projects to interoperate.

To make such analysis, you have to have a kind of "human" experience in the field you are developing the library, knowing the "folk lore" of the community. In this case the computer graphics community.
This is spot on, guesswork is good, but it's of little value without field experience. Things that looked like a good idea at the time may prove irrelevant (or cumbersome) in real use.

Fortunately, OpenTK is based on the needs of real software. Inertia, kanato, JTalton, Kamujin and everyone else, all started contributing due to the needs of their own projects. Right now, I'm using OpenTK for my diploma thesis, which gives a workout to the whole API. Interestingly, most irksome things I've encountered are related to math and fonts, things you've already posted about, objarni :)