pistondevelopers / graphics Goto Github PK

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

Needs to be supported.

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.

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

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.

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

This saves two vertices per extra triangle after the first.

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

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

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.

Does stuff for round rectangles.

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?

Needs to be supported.

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.

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.

Could buffering triangles make drawing faster?

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

This is for working with lines.

"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

Add shear transform to context.

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.

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.

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

Could be added to RectangleContext.

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.

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?

What settings works "good enough"?

It is hard to do in OpenGL?

Should Rust-Graphics have animated features?

What kind of abstraction would fit animation?

Would things as interpolation be sufficient?

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

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);

Should this be on by default?

How will it affect the performance?

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.

I could have a LeftToRightTextLayout and RightToLeftTextLayout.

Context is such an academic word...

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

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.

At the moment it does no transformation of the coordinates.

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

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

A TextLayoutContext could be created to position characters.

Each character could be drawn in a CharContext.

Assuming one wants to draw a rectange:

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

Should this create a new type?

Same code as for ColorContext.

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?

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:

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

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

Should use the clear_rgba feature of the BackEnd

This is useful for stuff like mouse position.