Does anyone know any 2D graphics library/crate that is as simple as Processing?

Does anyone know any other projects that does 2D graphics other than nannou and processing-rs ? Because when using the Processing language, it is far more simplier than the nannou project, while processing-rs appears to be abandoned. I just want something as simple as the Processing language?

I like macroquad for prototyping graphical programs. I’m not super familiar with processing but it’s good for drawing various graphics primitives.

Thanks I will check it out :slight_smile:

Do you where I can find the documentation/man pages for this project?

Good question! I usually google the crate name, end up at, and look for the documentation link there:

Not everything in it is documented but there are also good examples in the repository, though some of them work only on recent unreleased versions (you can ask cargo to give you the dependency via git rather than via if you want).

Ah I see. Thanks

I wanted to ask you some help in regards to understanding the code

use macroquad::prelude::*;

async fn main() {
    loop {
        draw_line(40.0, 40.0, 100.0, 200.0, 15.0, BLUE);
        draw_rectangle(screen_width() / 2.0 - 60.0, 100.0, 120.0, 60.0, GREEN);
        draw_circle(screen_width() - 30.0, screen_height() - 30.0, 15.0, YELLOW);
        draw_text("HELLO", 20.0, 20.0, 20.0, DARKGRAY);

#[macroquad::main("BasicShapes")] So what does this exactly do?

async fn main() Before calling the main function, how come we have to add this async word and what does it do exactly?

next_frame().await I believe this updates everything on the frame, however, what does this .await word even mean?

The macroquad::main("BasicShapes") macro wraps your async main function in a call which creates the configuration context and starts the async runtime. In the configuration you pass the information that the window should be labelled "BasicShapes".

Async main is chosen to be compatible with WASM targets (so you can run it in the browser). Since you cannot block in the JavaScript main thread you can circumvent the issue with polling the function repeatedly.

next_frame().await actually just inserts the await point mentioned before, it literally means "please wait until the next frame is to be rendered". The implementation of the future is quite simple as it simply flips between waiting states and therefore has a very low performance impact.

1 Like

So what is the async runtime?

So when it is being rendered, it means that all the shapes are being drawn before it reaches that next_frame().await function (e.g. draw_circle(10,20,50))?

As the macroquad::main macro points to Window which is the entry point for javascript which acts as the async runtime.

It's added to the rendering pipeline the moment you're executing the command (e.g. render_triange) and then rendered in the javascript main loop via miniquad's draw.

next_frame() is literally defined as returning a Unit-Struct which flips between Waiting and RunOnce and does nothing besides causing an await point where the rust compiler can segment the stack-state and prepare for future execution (which prevents javascript from terminating the execution as it's not allowed to block). In the javascript SAPP layer of the miniquad crate you can find the direct bindings which are then responsible for the rendering at the polling of the next frame. The glue code to javascript has the "glue layer" between the SAPP layer and the javascript world.

I hope that the explanation helps with the sections linked to the related github source code!


Thanks mate, one last question though, can this run on Windows without using a web browser? If so would it use JavaScript or is this if I am using wasm?

It runs natively, but the very well sourced explanation above referenced the specific case of running in a browser. The basic idea is the same on windows or Mac or whatever as well.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.