DEV Community: Ramayen

Frame Rate improvement for faster Rendering

Ramayen — Wed, 10 Dec 2025 00:00:00 +0000

In this article, we are going to go through following:

A basic reference of what the performance issue was.
Initial analysis approach with logging and results of logs.
Brief section about perf and how it can be used in this scenario.
Understanding the issue with flamegraph outputs.
Previous architecture of program and why it was used.
Exploring possible solutions and their limitations.
Results after application of optimal approach in performace.
Discussing further improvements in rendering and possible assumptions.
Concluding the article with updated flamegraph output with better performance.

Introduction

So, to give some context:

I have been making a library called Spell which provides a backend of slint to create desktop widgets for linux ricing.

There are a lot of words in the previous sentence which may not make sense. Let us go through them in reverse Desktop linux users may be familiar with the word "ricing". Daily driving linux as your primary desktop machine has a lot of perks. One get greater control over the OS (and hardware) and endless customizability options. One such customisation is a clean slate of "display" without any UI components. So you don't have top bars, app launchers, docks, panels, lock screens etc. This can be done when you opt out of using community maintained desktop environments (like gnome, plasma etc) and go on to just use a window manager (or wayland compositor in this case). The system thus configured remains extremely light and minimal. You can then install 3rd party tools or code these UI components yourself. People create their own workflows from scratch. This gives a fresh look to your desktop and the exact setup you want.

Traditionally, these UI components are made in GTK UI toolkit. Plasma (by KDE) uses Qt for its applications. To easy the development of creating these widgets/UI components, various people have created frameworks that applies abstraction over GTK to ease out the process. Rather than making another GTK widget toolkit, Spell explores a unique gap. It provides the backend of slint, a declarative language, to create these UI components. My choice of integrating slint for this use case is due to its versatility and great integration with rust which helped in the process of porting it to wayland. Now, I received a recent issue on CPU usage maxing to 100 percent when using spell. The article discusses how the performance is improved and the issue is fixed.

Initial Response

I wasn't surprised by the issue as I was also having some performance issues when using spell in rust's debug profile. I thought the problem originated from weak CPU power of my system but the issue confirmed that spell's rendering is not optimised and can be improved. I first added some print statements to see how long it takes to render a buffer( a chunk of memory where the UI's pixel data is stored, generally in the form of arrays) to screen. The result is following:

Skia Elapsed Time: 0
Normal Elapsed Time: 0
Release 110 @ (14.37109375, 29.28515625)
Keyboard focus entered
Keyboard focus entered
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 8
Normal Elapsed Time: 126
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 14
Normal Elapsed Time: 121
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 14
Normal Elapsed Time: 124
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 14
Normal Elapsed Time: 124
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 9
Normal Elapsed Time: 127
This trait implementation of RenderBuffer is Run
Skia Elapsed Time: 3
Normal Elapsed Time: 126
Skia Elapsed Time: 0
Normal Elapsed Time: 0

The section shows logs for a 200ms animation on the buffer. Some things to note:

When there no changes/interactions, the rendering time is zero milliseconds, this can be seen at the start and end of these logs.
Each buffer's repainting produces 3 logs, the time it took slint's backend skia to change pixel, represented by Skia Elapsed Time, the time it took to process for wayland by Normal Elapsed Time and if the frame is actually updated or not by printing This trait implementation of RenderBuffer is Run if true.
This log is the highest every time it took to produce a new frame, generally the time for Skia rendering varies around 9 ms and for processing it took around 32 ms on average, so though the value is fluctuating, (like here it took as long as 130 ms for a frame), on average it took 40 ms to produce a frame (in release profile).

This shows some scope of improvement, if it takes on average 40 ms to produce a new frame, for a 200ms, I was only getting 5 frame, hence resulting in jerky animations. So, these logs do help in understanding where the maximum amount of time is being taken, yet the hike in CPU can't be explained by logs alone, they provide the time data but not the computation details.

This shows some scope of improvement, if it takes on average 40 ms to produce a new frame, for 200ms, I was only getting 5 frames, hence resulting in jerky animations. So, these logs do help in understanding where the maximum amount of time is being taken, yet the hike in cpu can't be explained by logs alone, they provide the time data but not the computation details.

So, when searching for the tools to access the computational details, I recalled I had bookmarked this page on perfcommand when reading the mail of Andres Freud about the xz vulnerability (out of curiosity). Surfing further brought me to flamegraph (and extension cargo-flamegraphfor rust projects) which can show perf output into an interactive graph svg for better interpretation of program. So, let's understand a bit about how perf works.

How does perf work, in layman's terms

I was intrigued by perf and wanted to know how it works internally to produce such necessary performance information. Turns out, modern processors have special registers called Hardware performance pointers. As per Wikipedia, these store counts of hardware-related activities, which are further used for performance analysis in certain aspects. Modern OS kernels provide APIs to access information by these registers. This is exploited by perf. Flamegraphs then uses perf's metrics to produce these graphs, how to interpret them is best explained on their website. Quoting

The x-axis shows the stack profile population, sorted alphabetically (it is not the passage of time), and the y-axis shows stack depth, counting from zero at the bottom. Each rectangle represents a stack frame. The wider a frame is is, the more often it was present in the stacks.

Stack profile population is basically a trace of which functions are called and how often a function/instruction call occurs. So, with this info in place we can analyse some data output.

The Issue

When looking at the (rather boring ) perf output, I could only figure out the fact that a custom function of mine has a rather equal or more biased CPU percentage to Self than to the slint drawing it calls, but the structure of wayland involve various checks and callbacks, so the overhead mechanism of wayland was shadowing the data. So, I moved towards looking flamegraphs, which gave a rather clear picture. The primary graph looked like this:

A few thing to notice:

First of all ..ault::Default::default entry left of spell_framework::run_loop_onceis unrelated to the topic of analysis because it represents some other utility initialisation.
run_event_loop is the custom function called on each iteration of frame. First optimisation can be noticed here, the function calls block_displatchand a dispatching_impl(mark 2) methods wherein blocking_dispatch itself callsdispatching_impl(mark 1) internally. In a single iteration, the process of dispatching of events need not happen twice, so I removed blocking_dispatchin favour of calling blocking_read and dispatching_impl directly once. This brought some improvement. The changed code produced the following graph.

On further analysis:

run_loop_once calls 3 sequential functions in it, namely:
- flush : Flushes old requests of updation of the UI if pending.
- blocking_read: internal wayland function which seeks new requests. It uses half of it computational work in Self and almost half in callInnerEventGaurd::read, but since this is an internal function provided by wayland_client, there can be no optimisations by me.
- dispatching_impl: called by the event queue to run the callback function which renders the new frame. It internally calls SpellWin::converter(mark 1 ) which is a custom function I made. It has scope of improvement, let's zoom in to understand the distribution.
It is important to note that even though flush and blocking_read holds more space in the graph, they are repeated functions with very less computational work. They block to read input/events, the CPU works more in rendering the new buffer to pixels.

This graph tells a singular thing very prominently. the draw_if_needed(top right) function is what calls the Skia renderer on the buffer memory chunk to update the pixels, so of all the time converter takes to process, only about 25 percent is utilised in actual rendering, the rest is the processing of new information. It is at this point I understood what was going wrong. Here is a actual snippet for you to guess(though the function shouldn't make sense without context but I have added comments for help)

    fn converter(&mut self, qh: &QueueHandle<Self>) {
       // Initialisation and setting basic vars.
        slint::platform::update_timers_and_animations();
        let width: u32 = self.size.width;
        let height: u32 = self.size.height;
        let window_adapter = self.adapter.clone();

        if !self.is_hidden.get() {
             // Rendering from Skia
            let redraw_val: bool = window_adapter.draw_if_needed();

            let pool = &mut self.memory_manager.pool;
            let buffer = &self.memory_manager.wayland_buffer;
            let primary_canvas = buffer.canvas(pool).unwrap();

          // Converting slint array for wayland memory Buffer
            if redraw_val || self.first_configure {
                {
                    primary_canvas
                        .iter_mut()
                        .enumerate()
                        .for_each(|(index, val)| {
                            *val = self.core.borrow().primary_buffer[index];
                        });
                }
            }

           // Leftover layer calls for asking new frame and reattaching updated Buffer.
            self.first_configure = false;
            self.layer.wl_surface().damage_buffer(0, 0, width as i32, height as i32);
            self.layer.wl_surface().frame(qh, self.layer.wl_surface().clone());
            self.layer.wl_surface().attach(Some(buffer.wl_buffer()), 0, 0);
        }
        self.layer.commit();
    }

The issue is at line 19. Technically, this instruction copies every array element to the buffer. Element of buffer are simply u8 (unsigned int of 8 bits) values where 4 consecutive values represent a pixel (in RGBA format). So, on every frame the whole memory space carrying the pixels were being copied. This was an expensive process. For example for a 500 width and 800 height widget the memory array would be of length 500 * 800 * 4 = 1,600,000. And this array was copied almost every time.

So, now we know the issue. It is still important to understand why I wrote such code and how can I mitigate the copying by possible solutions.

Why this architecture was chosen

A spell window (called SpellWin) is composed of 2 components, the primary being the wayland part and secondarily an Rc (reference counter) to the slint backend (can be seen as self.window_adapter in the above code). The backend of slint is called for redrawing, parsing key input events, touch input events and cursor pointer input events.Buffer is a struct provided by Smithay (maintain's port of wayland in rust) for accessing the underlying memory which stores the pixels. The issue is that Buffer can't be passed to slint backend during the initialisation of SpellWin as its mutable reference is required for features like:

Hiding window from screen, without clearing the buffer.
Reappearing of window, without redrawing.
Showing only a section of Buffer.

As one may know, a mutable reference can't be accessed if value is behind a reference counter. Buffer can not be wrapped by RefCell due to some trait requirements. So, I came up with a SharedCore (a struct storing arrays of pixels for various buffers) wrapped in Rc<RefCell<>> and passed an instance to both slint and wayland. Then, when draw_if_needed was called slint made changes to SharedCore, later complete array of SharedCore was copied into Buffer for rendering. Both initialisation and rendering is shown below.

Initialisation :

Rendering of a Frame :

Exploring Solutions

So, what are my options here. Given the problem to share same memory chunk of Buffer between 2 separate processes. Let's explore possible alternatives and see if one can fit into this architecture. It is important to mention that Buffer doesn't implement clone. It is provided/ created by another struct call SlotPool responsible for creating buffers of various sizes. Also the fact that a Slotpool's instance is always necessary to grab the underlying canvas (i.e. &mut [u8]) of a Buffer to write over the memory directly.

The first and most direct approach is to merge the structs of slint's backend and wayland objects, that way wayland's wouldn't have to hold a stance of slint's backend, rather it would become slint's backend. The approach poses 2 primary restrictions which can not be overlooked.

Slint need a backend to be set for it to use it. Otherwise, slint chooses the default rendering mechanism to show the UI. This will end up in creation of an application window for desktop. This will not be appropriate as we want widgets to be made from slint.
Slint's platform setting mechanism expect an Rc wrapped instance of the new backend due to its structure of APIs. But then the whole window of slint and wayland would need to be wrapped and parsed. Resulting in the fact that all methods of SpellWin would need to be converted from &mut self to &self.

Another obvious approach is to pass both Buffer and SlotPool to slint, yet again this approach poses some issues of its own.

This makes my code less readable given the fact that the distinction between slint's backend and wayland's objects are not properly separated.
Even if they could be passed, all other functionalities of wayland reside within SpellWin directly. So even though the buffer could be updated directly, the change couldn't be transferred to an actual visual frame.

I did try to implement this architectural change and after 2 days of work I started bumping into runtime errors of reference already being borrowed mutable so I had to revert back.

Only when I was about to ask the same on a forum I decided to sweep the docs one last time to ensure these values can't be copied. There I came across a method of Buffer which yielded a struct called Slot. This was a basic object whose only job was to provide the underlying memory chunks. Surplus to it, Slot could also be cloned since all the clones would point to same pixels.

So, I came up with the approach that during initialisation, an instance of Slot of a Buffer would be passed to slint. When a new frame be called, Skia (slint's backend) would directly write to pixels via Slot, then buffer could be directly pushed for the new frame. Initialisation :

Rendering of a frame :

Expected results

So, after the work of another few days I was able to fight the compiler and brought this architecture into my code. The next thing was to check the performance improvements which this experiment bought, so I looked up the logs to find the rendering of buffers with an average of 8 ms. With all the copying time stripped, normal rendering of skia is at 8ms so it is all that was left. Hence, now a 200 ms animation had 25 frames rather than 5 which is a great improvement. With these changes in place I closed the issue with the Author of issue satisfied. Added "Massive performance improvement in rendering" in my CHANGELOG.md and called it a win.

Scope for more optimisation

When I started with this project, frame's rendering was at 140 ms, I brought it down to 40 and now 7ms. So, further changes may bring very light improvements. Also, with this rate the library will be compatible with a monitor of frame rate as high as 120Hz. Nonetheless, currently my loop runs indefinitely when there is no change in buffer. this loop should be brought to sleep for the frame rate of monitor rendering upon. Hence, preventing loops from over run. blocking the loop is not optimal as it hosts events from multiple sources and blocking on one would cause issues in submission of events from these other sources. Other improvement can be seen in line 30 of the code I provided.

Since damaging the buffer for a new frame takes a rectangular space in local coordinate system, this can be modified to enable partial rendering from the data skia provides. It would have to be seen though if extra computation of calculating rectangles is worth the time cut provided by partial rendering. Another metric which is left but should be considered is the actual time to render a buffer into frame.

Conclusion

So, with everything in place, here is the updated flamegraph of run_loop_once. You can notice that converter's time is mostly invested in calling the rendering only.

With this, we have reached the end of the blog, thanks for reading it. Provide any inputs and contact me for suggestions. Thank you and Happy Coding !

Hardened Scopes: A mental model for rust

Ramayen — Thu, 06 Nov 2025 00:00:00 +0000

In this article, we are going to go through following:

Explaining how rust works and how it should be though of.
Shortcomings of basic mental models when refactoring code.
Designing function signatures for less pain in large projects.
Role of better architectures for projects.
Concluding the article with brief summary.

Introduction

I came across rust almost two years ago now. It is so to say my first language that I learned seriously and all by myself. No tutorials watched. Just the books on the lang. I knew python before that but I was only 12 and I never cared to look beyond the basic control flow of the language. My world was confined in Jupyter notebooks and I never made something usable out of my understanding. Unlike python, I learned rust on my own and spend quiet some time in trying to deliver something open source to the community. I made a TUI application,a small framework, read the official rust book and completed rustlings. While writing code, an idea of model of how rust should be thought of occurred to me that I found good enough to share. As I came across a hell amount of issues while fighting the borrow checker. There is a common pattern that I was doing wrong almost always.

Borrow Checker can be thought of as a sub-program of rustc compiler that checks the ownership rules in a code snippet. Ownership rules are discussed below.

The most widely used way of understanding the ownership rules for the lang is to think of references and mut references as pointers (like in C) and reason about the requirement of that variable in a function or block. If you want to read the data, a normal reference should be used. If you think that the data might be changed or modified in a code block then the reference should be mutable. Example:

fn main() {
  let interest: u32 = 10;
  let years: u32 = 7;
  // Amount represents the total amount, initially it is equal to principal
  let mut amount: u32 = 10045;
  simple_interest(&mut amount,interest, years);
  println!("The amount to be repaid: {}", amount);
}

fn simple_interest(amount: &mut u32, interest: u32, years: u32) {
  *amount = *amount * (1+ interest * years);
}

Here you can see that on running this program with command rustc filname.rs, we get the amount.

The concept is pretty simple and precisely fits what the ownership rules try to say. The problem is, when you enter into real world and start building something in rust while keeping this philosophy, it feels pretty scarce. I mean you will face very basic ownership errors and the compiler shakes pretty well. I agree that refining comes after you do a ton of mistakes, specially in rust.

Still, a better sense of the language can be provided to mitigate it and start off with better ground. The objective is not to make the beginner avoid mistakes but give them a better perspective of what they are actually writing and not just wait for the compiler to point it out ( the rush and excitement after knowing something is wrong before LSP points it out is satisfying, I felt it for the first time when I was sure that explicit lifetimes would be needed in a function signature before the compiler pointed it out). Thus, with the intro in place, Let's get started on thinking rust better.

Refactoring and code isolation

Let us first get a grasp of how ownership is implemented in rust. It is a common notion that ownership is all about references and which variable "owns" what in the memory. It is more than that. Actually, the ownership is implemented at the end of scopes.

As a scope ends (with a delimiter }), the owners in that scope are dropped according to ownership rules:

The ownership rules are:

Each value in Rust has an owner.

There can only be one owner at a time.

When the owner goes out of scope, the value will be dropped.

So, don't worry about references. Rather, worry about scopes. They are the devils. They drop variables and clear values in heap. Think of scopes as a kind of box/ machine that takes in objects(references and moved variables) but doesn't give them out very easily. Rather, it is very choosy in what to give away. A very practical example for this kind of nature can be witnessed when following the usual software development cycle. When fitting the application logic into code, we often put a ton of functionalities in single functions just to make things work. Then we refactor. Then we create some tests, fail them, add some code and refactor again.

As a general rule of programming, a single block (by block I mean a function, struct, enum etc) should not do more than one (or at max two) tasks.So, following this software development cycle with a rust project creates a lot of friction in the refactoring part. As said before, refactoring code ( particularly separating code into separate helper/secondary functions) in rust is the main( and the first) place where you tussle with the borrow checker. Why? Think of it, when refactoring code you are essentially bringing auxiliary tasks into separate reusable components. But in doing so you are putting the code in another scope (in a sense) inside your normal function. You can see the issue easily by placing the auxiliary code inside a scope and see a ton of moved there, variable cant be used or use of moved value kind of errors.

Here is a example of code (with improper error handling) that takes in 2 strings containing equal number of -- separated integers and adds the corresponding values to produce another string.

use std::io;

fn main() -> io::Result<()> {
    let mut first_string = String::new();
    let mut second_string = String::new();
    let mut output = String::new();

    loop {
        println!("Enter the first string (Type END to suspend)");
        io::stdin().read_line(&mut first_string)?;
        if first_string.trim() == "END" {
            break;
        }
        println!("Enter the second string (length should be same as string one)");
        io::stdin().read_line(&mut second_string)?;

        let first_in_vals: Vec<u32> = first_string
            .split("--")
            .map(|val| val.trim().parse::<u32>().unwrap())
            .collect();
        let second_in_vals: Vec<u32> = second_string
            .split("--")
            .map(|val| val.trim().parse().unwrap())
            .collect();
        for (index, val) in first_in_vals.iter().enumerate() {
            output = format!("{output}--{}", (val + second_in_vals[index]));
            if index != first_in_vals.len() - 1 {
                output = output + "--"
            }
        }
        println!("Result: {}", output.chars().skip(2).collect::<String>());

        // Since read_lines append the text input, it is important to clear the previous text.
        first_string.clear();
        second_string.clear();
        output.clear();
    }
    Ok(())
}

Let's save it into summation.rs and compile with (make sure rust and its compiler is installed, view Official Guide):

rustc summation.rs

Run the program's binary with some sample input and it will work fine with the given constraints on inputs. Now suppose we have a large codebase and we want to abstract all the printing functionality separately. Change line 31 withprint_out_result(output); and add the following function below.

fn print_out_result(output: String) {
    println!("Result: {}", output.chars().skip(2).collect::<String>());
}

Do the changes and compile...

See! You get the error[E0382]: use of moved value: 'output'. Thus, one may notice that even such a trivial change won't work as expected if you will not keep the borrow checker in mind. Of course, as suggested by the compiler, you can clone the string and move on but it is more work than putting code in separate functions and getting done with it.

Now, think in terms of scopes and answer some fundamental questions:

Where is the need to define the variables?
- Many a times when writing a program some variables were getting declared from some other code /function and they can be created inside rather than being taken as an argument.
- As an example, in the above code snippet, you can remove output.clear();by initialising output inside the loop, thus it gets renewed on each iteration.
Does your helper component needs to consume the value eternally?
- This is a important question. Various times a value needs to be transformed (like converting a queryable diesel struct into another struct used across your application) rather than being used for creating something else. In such cases the value needs to be moved.
- If the value( of the variable) needs to be read and changed and also used later, the you don't want your } delimiter to eat it, hence use the references.

Extra Info : If we are taking and returning ands returning more than one reference, then we need to explicitly state the lifetime of the objects. It is an issue as explicit lifetimes tend to percolate to the parent derived data types.

As in the above example, rather than cloning, you could change the signature of print_out_result as fn print_out_result(output: &mut str) and pass mutable reference of output in the function call. This prevents unnecessary hard cloning of strings.

When answering these questions, you will precisely know what to move and what to give reference to.

Designing function signatures

Even before refactoring, the borrow checker and strict rust compiler introduce themselves as soon as you start getting out of your standard main function and start to build new functions. Function signatures are a whole game in itself in rust. Hey Bhaumik, then why this section is after the refactoring part?

Function signatures do come first but in my experience they don't create much nuisance in small code bases. You really need to give them a thought when designing your project. The arguments that a function can take(i.e. its interface) in rust is not just data types like in other programming languages. It can take data types, references to data types, mutable references to data types, data types wrapped in Types like Result and Option and data types wrapped in smart pointers like Rc.

This becomes a significant part then. I wouldn't go on to write more questions for you to answer for resolution. Ultimately you need to focus on what you can tolerate to be eaten by } and what you can't and that decision goes up to the thinking of where you want to use those objects later, what are their objectives etc.

For example at various places you need to remember that doing .clone() might be a workaround for the compiler error but doing so can create a logical bug in software. Since, clone creates hard copies of objects, that means if your object is storing some state of your program, then creating copies will lose that data.

Ending this small section brings me to the last part that needs to be addressed before concluding the article. If you notice, most of the times the fight with borrow checker starts when you expand your ideas beyond a certain scope. Thus designing of function signature ultimately relates to how you are design your program for real world applications.

Software Design

Though completely out of scope from the motive of this article, I found it compulsive to add a note on importance of how you think the processes of your program. For example, I created a TUI application for the purpose of practising rust. Then I converted it to multi threaded for taking keyboard input events from a separate thread.

Converting the app from a single to multi-thread design required some significant alteration which led to breaking of software thrice! I couldn't get my head around using Arc and Mutex properly. Though I manged to achieve the task by using mpsc(Multiple Producer Single Consumer) channels, I was stuck at this issue for a week or so because of 2 issues:

I didn't thoroughly thought about how I want to achieve the muti-threaded nature.
Borrow checker made it a lengthy task to quickly change code across files to try a new approach.

All I want to say is that some clarity about what your trying to achieve and how you are trying to achieve is important. It may be good to take help from diagrams or arrows to draw out the basic control flow with pen and paper.

Conclusion

This brings us to end. I hope by this time you would have got a descent idea on how to up skill your rust programming. The article talked about an approach to think about rust's ownership rules while trying to build something great. It went through how other methods fell short, how you can think in terms of } / end of scope, how these methods apply in code refactoring and function creation and in the end how a better software design always give an upper hand. The article doesn't follow today's trend of keeping things crisp and too much on the point that it might leave some essential background. This is fine with me. I am not a seasoned programmer, I am an enthusiast at learning new things and open for any suggestions for improvement. Suggestions and typo fixes can be send to ramayenin discord. Keep experimenting and Happy Coding !