I would like to avoid Result use because it make the code look uglier

What about calling unimplemented!() instead?

Do I need a line intersection algorithm?

It could be useful to pair two values, one as a base value and one as current value.

Base color vs Current color
Base transform vs Current transform
Base control points vs Current control points

Could have a test suite for reading and writing to image formats.

It should be easy to integrate with back-ends.
Some libraries might have a collection of back-ends.

The source docs about the BackEnd trait should provide details about the expected behavior.

http://www.ludumdare.com/compo/2014/04/23/a-2d-graphics-engine-in-rust/

I could have a LeftToRightTextLayout and RightToLeftTextLayout.

A triangle list with colors per vertex would be the easiest for now.

One idea is to develop a default back-end that just structures the drawing calls into a data structure. The structure can then be fed back into the context, generating a new structure, and checking that those two structures are the same.

The graphics API and the node tree should then be of the same complexity. A such node tree can be sent across the network, read from a file etc.

Context::rgba -> ColorContext 4d9631c
Context::rect -> RectangleContext eebb0c7
ColorContext::rect -> RectangleColorContext b1b20a7
RectangleContext::rgba -> RectangleColorContext bde9ae5
RectangleColorContext::fill b1cb185

Computer graphics is a complicated subject, but there are certain things that are universal:

• You want to change the context dynamically
• You want to undo recently changes to the context
• You want to know what is going on in the context
• You don't want to keep track of changes required to undo changes
• You want to check for hit test and get context relevant information
• You want to work with context specific methods to build patterns etc.
• You want good defaults

The enum in Rust allows one to create a building block for both values and pointer to values:

I assume in order to make decisions about which direction to go, one needs to run the same tests using different algorithms.

Should use the clear_rgba feature of the BackEnd

I need to collect the necessary information to deal with fonts.

• Is is much work to write a pure Rust decoder of various font formats?
• Is is much work to deal with globalization, right-to-left etc?

At the moment it does no transformation of the coordinates.

Add shear transform to context.

The BackEnd should implement a method to clear the entire surface with one color.

I don't like platform specific GUI, because it makes the behavior and look of the application in-deterministic. One need to test the application for every new feature on all the platforms.

Same code as for ColorContext.

The word back-end implies that one is adding a target in an existing package.
Rust-Graphics is designed to build the 'back-end' on top, such that one can write a new 'back-end' in the same application one uses it.

2D matrices are kind of special, because they only require 6 numbers which reduces computation. The natural way of writing a unit matrix is:

[1.0, 0.0, 0.0,
 0.0, 1.0, 0.0]

In the end, matrices are just arrays with numbers, so I would like to just use

pub type Matrix2d = [f64, ..6]

Need this in the basic context.

Assuming one wants to draw a rectange:

.rect(0.0, 0.0, 100.0, 100.0).draw();

Should this create a new type?

"Due to an odd quirk of OpenGL, writing to the depth buffer is always inactive if GL_DEPTH_TEST is disabled, regardless of the depth mask. If you just want to write to the depth buffer, without actually doing a test, you must enable GL_DEPTH_TEST and use the depth function of GL_ALWAYS."

Source: http://www.arcsynthesis.org/gltut/Positioning/Tut05%20Overlap%20and%20Depth%20Buffering.html

Need a way to render to textures, such as exporting an image.

Instead of wasting time reimplementing image formats in pure Rust, one could have a simple enough back-end to wrap around various formats.

I imagine having an enum that contains commonly used image formats. A function takes the raw data of an image, writes to a file in a given format. The enum can have methods that returns default file extensions and detects version from file extension.

image::write(file, img);
image::write_format(file, img, format);

Could buffering triangles make drawing faster?

I think it is best to think things through a little while and engage others when there are specific tasks to do. It takes a quite bit of work to come up with a design that addresses all the concerns. In that process I might need some input, but so far this is a kind of project I can deal best with by working on it in peace.

Should this be on by default?

How will it affect the performance?

What settings works "good enough"?

It is hard to do in OpenGL?

https://github.com/andelf/rust-sdl2_ttf

Libraries like these could be very common. Perhaps fonts could bypass directly to the back-end and provide helper methods for writing back-ends.

Piston is an OpenGL-ES back-end for Rust-Graphics.

Context is such an academic word...

A function that returns true if a point is inside a rectangle.

Could be added to RectangleContext.

Needs to be supported.

This saves two vertices per extra triangle after the first.

Assuming that most methods inline everything, the compiler should be able to determine that

.trans(1.0, 0.0).trans(0.0, 1.0)

only create pointers to the other fields, but does not use them.

How can one check that this is the case? Is it possible to see that by looking at the emitted IR?

One algorithm I often find useful, is centering a rectangle inside another rectangle while trying to be as large as possible.

A TextLayoutContext could be created to position characters.

Each character could be drawn in a CharContext.

Needs to be supported.

Does stuff for round rectangles.

This is for working with lines.

f32 has problems with matrices since it requires very good precision specially in the range between 0.0 and 1.0.

Using f64 has the advantage that I = M^-1 M can have a larger invariant space and still be true under a certain epsilon absolute value.

Most CPUs are 64bit now and the speed of f64 will increase with the development of technology.

Having a nice syntax counts, but having battery included also means a lot. Most people might become interested when they see the syntax. After a while they will see the things that are missing and then drop the project. It is important to keep enough speed in the development until it reaches a point where it is usable. The goal is to create the best portable 2D graphics library for Rust in the world. This means I have to think things through to the degree that it feels complete.

If we can't manage to create a such library or if there are any major obstacles, I would like to know sooner than realizing that weeks later. It might be necessary to reduce the scope of the project, but there are certain things people expect a graphics library to have.

The Shoes framework repository has almost 2000 commits, which is about 20x times the commits in Rust-Empty. Assuming that this project is going to be 20x times harder than Rust-Empty it would require a lot more man hours.

This is useful for stuff like mouse position.

Should Rust-Graphics have animated features?

What kind of abstraction would fit animation?

Would things as interpolation be sufficient?

For example, a back-end that renders deformed graphics could be generated using base and current control points.

One way is to have context wrap a generic type T:

pub struct Context<'a, Backend> {
  ....
   backend: &'a Backend
}

I think that Processing and Shoes are good frameworks to learn from. Would like Rust-Graphics to have many of the features of Processing but also the easy of use of Shoes.

http://www.processing.org/

http://shoesrb.com/

I think this should be a separate object than RectangleContext, even those two are similar. The reason is I would like to use circle etc. instead of square and make it mean something different.