black screen using with raqote

[tiye]

Long time since jrmuizel/raqote#75 and I finally managed to made another attempt. https://github.com/calcit-lang/calcit-paint/blob/raqote-prototype/src/main.rs#L260-L288 but it only shew a black window on my macos. Could you help me locate the problem?

The example with Shape::new(..) worked on my laptop, I thought my code is mostly copied the logics, it should at least draw something. But got nothing.

[parasyte]

This isn't an issue in pixels, requests like this are better suited in the discussions page.

The bug in your code is this line: https://github.com/calcit-lang/calcit-paint/blob/b2c8768b019cc8b11d38ddf087debfdbe4c78279/src/main.rs#L272

You are cloning the pixel buffer and writing to a clone that pixels will never be able to see. Delete this line and it shows white text on a black background. (I do not know what the expected result is, but this is better than a pure black screen!)

Since this isn't a bug on our end, I'll close this issue. If you would like further assistance, please create a new discussion thread! I'll be glad to help in any way I can.

[JMS55]

@parasyte btw, discussion page is not enabled for this repo

[parasyte]

😐 Dang, I can see the tab on my side. Thanks GitHub for not being helpful at all!

[tiye]

Thanks for the help.

Maybe "Convert to Discussion"? I don't have permission on my side.

[parasyte]

Good call! It is done.

[tiye]

This how it looks finally:

[tiye]

I'm using this toy to simulate interactive shapes built with PIXI.js https://github.com/Quamolit/phlox.calcit . I supposed I could get a cheaper version without overhead of a whole browser. The framework part is at https://github.com/calcit-lang/corokia but bad news is that interpreter is really slow for animations.

As it turned out at current, winit does not respond very quickly as I move my mouse. Do you have any advices if I program the toy to respond to my mouse actions like dragging?

[parasyte]

hmmm. This really shouldn't be a problem with winit. The first suggestion I have is to make sure you are testing in release mode, E.g.:

cargo run --release -- calcit/compact.cirru

Debug builds are default, and they are known to be very poorly optimized.

The second suggestion I have is making sure you are using the right GPU if you have a multi-GPU system. pixels will try to use the high performance adapter if it can, but the best way is with something like env_logger to enable trace logging and print out the adapter that is being used.

Other than that, you might be able to do something like disable VSync and write a simple FPS counter to see what kind of performance you are actually getting.

Keep in mind that the bottleneck may be on the CPU-side specifically, and not the GPU side. Writing to a large pixel buffer with the CPU is always slower than using the GPU. So take note of both the canvas size and the scene complexity with raqote.

For comparison, when I run the raqote-winit example in this repo on my desktop, I can get over 1100 fps with wgpu::PresentMode::Mailbox. The specs are:

• Windows 10
• Ryzen 9 5900X
• GeForce RTX 3090
• 400x400 pixel buffer
• 3 raqote draw calls (e.g. shapes)

Your code is doing a "reactive" rasterization, so it is almost entirely independent of CPU cost for raqote or large pixel buffers. Even still, running it as-is on the same hardware shows about 1.5ms on screen while I move the mouse around. I don't know exactly what it is showing, but it appears to be the time spent in a VM? Whatever it is, it isn't even the most expensive part! Check out this patch:

diff --git a/src/main.rs b/src/main.rs
index c6a9c99..74bcbe1 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -26,7 +26,7 @@ use std::{thread, time};

 use notify::{RecommendedWatcher, RecursiveMode, Watcher};

-use pixels::{Pixels, SurfaceTexture};
+use pixels::{PixelsBuilder, SurfaceTexture};
 use winit::dpi::LogicalSize;
 use winit::event::Event;
 use winit::event::WindowEvent;
@@ -134,7 +134,10 @@ pub fn main() -> Result<(), String> {
   let mut pixels = {
     let window_size = window.inner_size();
     let surface_texture = SurfaceTexture::new(window_size.width, window_size.height, &window);
-    Pixels::new(WIDTH, HEIGHT, surface_texture).unwrap() // TODO handle error
+    PixelsBuilder::new(WIDTH, HEIGHT, surface_texture)
+      .present_mode(pixels::wgpu::PresentMode::Mailbox)
+      .build()
+      .unwrap() // TODO handle error
   };

   let mut draw_target = DrawTarget::new(WIDTH as i32, HEIGHT as i32);
@@ -257,6 +260,7 @@ pub fn main() -> Result<(), String> {
         // some break
       }
       Event::RedrawRequested(_wid) => {
+        let start_time = Instant::now();
         let event_info = handlers::handle_redraw();
         handle_calcit_event(
           &mut draw_target,
@@ -264,8 +268,10 @@ pub fn main() -> Result<(), String> {
           &event_entry,
           im::vector![event_info],
         );
+        println!("calcit time: {:?}", Instant::now().duration_since(start_time));

         // handle on redraw request
+        let start_time = Instant::now();
         for (dst, &src) in pixels
           .get_frame()
           .chunks_exact_mut(4)
@@ -276,7 +282,9 @@ pub fn main() -> Result<(), String> {
           dst[2] = src as u8;
           dst[3] = (src >> 24) as u8;
         }
+        println!("pixel buffer fill time: {:?}", Instant::now().duration_since(start_time));

+        let start_time = Instant::now();
         if pixels
           .render()
           .map_err(|e| error!("pixels.render() failed: {}", e))
@@ -284,6 +292,7 @@ pub fn main() -> Result<(), String> {
         {
           *control_flow = ControlFlow::Exit;
         }
+        println!("pixels.render() time: {:?}", Instant::now().duration_since(start_time));
       }
       Event::RedrawEventsCleared => {
         // println!("redraw events cleared");

On the same hardware mentioned above, this patch prints out stuff like this:

event: ({} (:type :mouse-move) (:x 969) (:clicks 1) (:y 5))
calcit time: 5.3877ms
pixel buffer fill time: 203.8µs
pixels.render() time: 360.7µs

event: ({} (:x 967) (:y 1) (:clicks 1) (:type :mouse-move))
calcit time: 5.2762ms
pixel buffer fill time: 202.3µs
pixels.render() time: 326.3µs

The "calcit time" encompasses all of handlers::handle_redraw() and handle_calcit_event(), and importantly it takes 3.5x more time than what is shown on screen. Meanwhile, filling the pixel buffer and copying it to a GPU texture takes about half of one millisecond on this machine. And this is relatively fast hardware. On my laptop, the screen showed 5.7ms, so I could extrapolate that to about 20ms per frame to handle all the VM stuff. Since that is over the frame budget for 60 fps (16.667ms), it could explain why you are experiencing issues handling mouse events,

From this oversimplified analysis, I would say the issue lies somewhere in your interpreter. And I can't really give any insight here. But I can recommend some profiling tools like flamegraph. For more targeted profiling, there is puffin and puffin_egui if you want to set it up. (You can use our egui-winit example as a starting point for integrating egui). There are a lot of profiling tools. Have a look at https://crates.io/crates/profiling/1.0.3 for a short list of some options.

I don't know, I'm kind of outside of my familiarity here, since the code that I've identified is unrelated to anything I've worked on. But maybe this short analysis can point you in the right direction!

[tiye]

Thanks for so much details. Tried the changes you mentioned above, and it's also very fast for Pixels to render. What's the purpose using PresentMode::Mailbox here? although I don't think it change much of the result if I don't use that.(not sure if it really taking effects on my macos...)

I really should try more tools for profiling. previously I tried flamegraph but it failed on large projects so I didn't really try it in this project.

[parasyte]

What's the purpose using PresentMode::Mailbox here?

Well, I was just stabbing in the dark. You don't really need this. Should probably just leave the default behavior. Mailbox and Immediate presentation modes are really only useful if you want to manage frame rate yourself for some reason. Or if you want to test ultra-low latency and don't mind screen tearing.