Update README.md

- Addresses gfx-rs#108
- Closes gfx-rs#157

README.md

@@ -4,7 +4,54 @@
 [![Gitter Chat](https://badges.gitter.im/gfx-rs/gfx-rs.png)](https://gitter.im/gfx-rs/gfx-rs)
 [![Stories in Ready](https://badge.waffle.io/gfx-rs/gfx-rs.png?label=S-ready&title=issues)](https://waffle.io/gfx-rs/gfx-rs)
 
-A lightweight buffer, shader and render queue manager for Rust.
+`gfx-rs` is a high-performance, type-safe and memory-safe, [retained mode]
+(http://en.wikipedia.org/wiki/Retained_mode) graphics API for the Rust
+programming language. It aims to be the default API for Rust graphics: for
+one-off applications, or higher level libraries or engines.
+
+## Why did we create gfx-rs?
+
+- Graphics APIs are mostly designed with C and C++ in mind, and hence are
+  dangerous and error prone, with little static safety guarantees.
+- Providing type safe wrappers around platform-specific APIs is feasible, but
+  only pushes the problem of platform independence to a higher level of
+  abstraction, often to the game or rendering engine.
+- [Retained mode](http://en.wikipedia.org/wiki/Retained_mode) graphics APIs,
+  whilst providing a high level of performance, often have a much higher
+  barrier to entry for most programmers than [immediate mode]
+  (http://en.wikipedia.org/wiki/Immediate_mode_%28computer_graphics%29) APIs.
+
+## Goals
+
+`gfx-rs` aims to be:
+
+- a API, not a framework
+- high performance and low latency
+- type-safe and memory-safe
+- compatible with Rust's concurrency model
+- designed to encourage best practices
+- extensible, with support for custom:
+    - device backends (OpenGL, Direct3D, Mantle, etc.)
+    - context backends (GLFW, SDL2, gl_init_platform, etc.)
+
+## Non-goals
+
+`gfx-rs` is not:
+
+- a rendering engine
+- a game engine
+- bound to a specific maths library
+
+`gfx-rs` will not handle:
+
+- window and input management
+- mathematics and transformations
+- lighting and shadows
+- visibility determination
+- draw call reordering
+- de-serializing of scene data formats
+- abstractions for platform-specific shaders
+- material abstractions
 
 ## Getting started
 
@@ -37,42 +84,6 @@ See the [triangle example](./src/examples/triangle) for an example using both.
 make -C src/examples
 ~~~
 
-## The Problem
-
-- Graphics APIs are difficult and diverse in nature. We've seen Mantle and
-  Metal popping out of nowhere. Even for OpenGL there are different profiles
-  that may need to be supported.
-- Communicating with the driver is considered expensive, thus feeding it should
-  be done in parallel with the user code.
-- Graphics programming is dangerous. Using Rust allows building a safer
-  abstraction without run-time overhead.
-
-## Design Goals
-
-- Safe but non-limiting higher level interface
-- Simple, lightweight implementation
-- Low performance overhead
-- Graphics API agnostic (OpenGL/Direct3D/Metal)
-- Maths library agnostic
-- Composable (a library, not a framework)
-- Compatible with Rust's task-based concurrency model
-- Clear documentation with examples
-
-## Possible Solutions
-
-- Verify compatibility of the shader inputs with user-provided data.
-- Use Rust procedural macros to generate the code for querying and uploading
-  of shader parameters.
-- Make use of 'draw call bucketing'. See [research.md](wiki/research.md) for more information.
-- Leave scene and model management up to the client, and focus instead on
-  buffers and shaders.
-- Provide structural data types (as opposed to nominal ones) in order to make
-  interfacing with other maths libraries easier. For example:
-~~~rust
-pub type Vertex4<T> = [T,..4];
-pub type Matrix4x3<T> = [[T,..3],..4];
-~~~
-
 ## Note
 
 gfx-rs is still in the early stages of development. Help is most appreciated.