An quick overview of the Sierpinski Triangle
“Sierpinski Triangles” are something which I have always been curious about. In more recent times there has been an influx of interest in it largely due to the emphasis and spotlight put on frontend frameworks. I should prefix this by saying I am no expert on the subject, just a fan.
What is a Sierpinski Triangle
“A fractal and attractive fixed set with the overall shape of an equilateral triangle, subdivided recursively into smaller equilateral” — Wikipedia
So a triangle with recursively more and more smaller triangles inside. Typically in the form of below.
How does it work?
Essentially consists of 3 steps
- Start with an equilateral triangle.
- Subdivide it into four smaller congruent equilateral triangles and remove the central triangle.
- Repeat step 2 with each of the remaining smaller triangles forever
Due to its simple iterative nature it is relatively easy to write a small program (with a given framework) which builds our structure, then alter it at certain time intervals and finally measure the impact of these changes. The alteration is usually in the form of a DOM change.
What do we measure?
As we render and re-render DOM nodes we can monitor the “FPS meter“ and the “GPU speeds”.
To do this on Chrome. Open Devtools -> Rendering
Then enable the FPS meter. A widget will appear in the top right of the browser tab, displaying “Frame Rate”, “GPU Raster” and “GPU Memory”.
From here we can get an idea on how the browsers CPU/GPU is handling the current triangles processing.
Why is it useful?
The process can be used for comparing the performance of certain algorithms. The more optimal the algorithm, the faster or cleaner the triangles render and re-render.
Imagine a complex website or game, something where the DOM is often throttled with content or layout changes. The better the rendering algorithm the less chance of “jank” the user will experience. The result is it will feel responsive and any clicks, interactions or animations will feel smooth and not leave the user frustrated. This means that it can be a massive selling point for frameworks which perform well at it.
It is actually often possible to visually notice improvements (as it is easy to scale structures up to such a point), which can make debugging and tweaking of algorithms a much easier job.
A couple of real world examples of where ST has been used to prove rendering performance:
What using it has taught me?
I had a go at building my own using only native Javascript (on my Github here). It took about 15–30 minutes from scratch and does not involve much code (it is quite crude).
I followed the general practice of creating a large ST and changing each triangles width as well as the text inside each node at given time intervals. The writes were always batched.
What I found was that using the window.requestAnimationFrame was incredibly useful. It is an event which is called directly before the next repaint. By only writing inside its callback it only performed a single and very performant repaint, and therefore had less DOM throttle. Something to note is that it is able to run this callback 60 times per second, but has the intelligence to match the displays refresh rate in the browser.
So considering I was getting a top “Frame Rate” of 1 fps before using it and 50 fps after, I have definitely realised just how important the particulars are when it comes to rendering performance.
Overall I felt like my experience has given me a fresh appreciation for how hard the creators of frameworks such as React/Vue/Angular have worked to get things to run so smoothly and in an idiomatic API.
I have much to learn on the topic still so if you have any issues or thoughts please let me know.
Also if you think this is in any way interesting, or even hilarious to see my calamity of an insight, please spare a clap ;)
Thanks x
