Just a quick post to report on my findings of measuring the energy impact of three different ways to have Spotify playing in the background: the Spotify app and the web player using two different browsers (Safari and Firefox).
Inspection of the package contents of the desktop app reveals it to be just a container version of the web player, bringing with it its own instance of a Chromium Embedded framework (for a whopping 168 MB, no less). So what we are really seeing is the performance of the web player in three different browser engines.
So here are the numbers, taken from the ‘energy’ tab in Activity Monitor, on a Mac Book Pro 15″ (2017), and in all cases the window was invisible off-screen*. I also included iTunes playing a local file for comparison:
Web player in Safari 14.0
Web player in Firefox 86
Spotify App 1.1.53 (Chromium embedded)
(*the respective app was first expanded full screen, and then the focus was switched back to the desktop so that the app window was totally not shown, not even a minimized window or icon)
And the winner for running Spotify with the least energy impact is actually the Safari browser. Congratulations to the Apple engineering team! The desktop app running Chromium Embedded comes second (but with a curiously high idle activity), while Firefox only comes last.
In the hope that this information was useful, make of it as you will :)
EDIT: I just learned that the web player does not support loudness normalization so it is not even an apples-to-apples comparison!
(Edit 2021: In the latest Safari 14.2 the Shadertoy does not work and my crash or hang the display. This is unfortunately a regression.)
This is a quick post thrown together to report on my experience with the new Safari 14 regarding support for WebGL 2. The news of improved WebGL support was floated last month in the Shadertoy Community Group:Fast forward to today and the Safari 14 update has now come to my laptop (which still runs macOS Mojave). So the first thing I did check out all my shaders on Shadertoy and then some to see if the promises were true. My verdict (TL/DR):
This page is my personal collection of highlights from GDC 2014. I was not able to attend in person, so I had to rely on Twitter to get updated. The immersion was not perfect, but some of the thrill was definitely carried over. So here it goes (in release order): Weiterlesen →
I found my copy of the book in the mail today. I was a little surprised by the moderate size—other volumes of this series were just that: volumes! I think this one is about half the size than the previous tomes. By the way, this post is a shameless plug because there is an article written by me in it. Thanks go to Wolfgang Engel, the series editor, and Christopher Oat, my section editor, and CRC press for making it possible! I will post some comments on the other articles when I read them through.
I found one very good and comprehensive article on data driven engine design by Donald Revie. The ideas presented in there resonate very well with the designs that I found worked well in the past, so this part gets a solid +1 from me.
(I ended up with a triad of IRenderObject, IRenderGeometry and IRenderProgram, where the render object would AddBatches() to a draw list, each of which refers to one geometry containing the mesh and one program for setting the render state. For instance, a SpeedTree™ render object would typically add three batches, one for each of the branches, fronds and leaves, where each batch would pair the specific geometry with an appropriate program. The draw list is then sorted in one go via a general 128 bit sort key, and the batches rendered in order. This system is general enough that the UI system also can just AddBatches() to this list (so the UI system, as a whole, is just one instance of a render object). In this case, the individual UI geometry objects just represent views into one big dynamic vertex buffer. I probably want to explain this system in detail in another post.)
Another two very inspiring articles so far are the one about geometric postprocess antialiasing, by Emil “Humus” Persson, and the piece about global illumination using a voxel grid, from the teams at the Unis Koblenz/Magdeburg. I already read their ACM paper before and I think it is a viable method.