Nah, of course not! It's fair game (otherwise you'd first have to invent the universe). It was just the speech synth API was pretty new when I did that, so it felt sneaky ;)
Also - p01, you are a hero to us all. MONOSPACE is beautiful, congrats on the Assembly win!
The main part of the source code is the last `for(...)` loop that updates the sound buffer, and draws the text.
There was not much inspiration :p I needed something simple enough to be fairly compact and sound melodic.
So I used a chord of 4 notes, played them at different speed and octaves. The lead using a sinus oscillator to get nice pure tones, a deeper sound 4x slower with a pulse oscillator to get more edgy sound, the deepest sound 16x slower with a sawtooth to get a gritty bass. Layered with the perspective scaling of the dots to get something bleeps in synch with the visuals.
I do not use any minifier. I minify the code by hand, and typically prototype ideas and performance tests in normal non-minified code. Once the main idea and approach are settled, I minify the code by hand and keep an eye on the heatmap of the DEFLATE stream to match the 1024 bytes limit.
MONOSPACE took ~4months on an off to create, tallying ~60h of work. You know 2020 + trying to balance work & family, and remain sane these days.
As I said on my site, the Audio and Visuals feed each other to make the background noise based on each dot, and the camera shake based on the Audio. That way I keep the Audio & Visuals are perfectly in synch, for free ;)
For the X & Y camera shake, I use the values 0 and 64 from the Audio buffer. The 64 is because this is the maximum number of characters rendered by the Text writer which happens in the loop updating the Audio buffer. Using something lower than the 64th value would make the last characters of the Text shake in a different way than the rest.
He is very talented and was nice enough to implement a couple of features to help with this kind of productions when I was working on BLCK4777 - https://www.p01.org/BLCK4777
I made 100s of creative projects and failed experiences before getting there. Don't get scared by that number. All it means, is that it is possible to do in 60h. Some would take 600, others 20.
I threw that number away to put it in context with the 4 months since the first prototype. I could only work from time to time. Some times not touching the code at all for weeks.
Hi, my bad. I forgot to set the Transfert Type to binary on my new laptop :p
Hope you enjoy MONOSPACE anyhow. I am pretty happy with how it turned out. I believe I managed to nudge a little the state of art of what type of camera work is possible in 1kb demos.
I believe this is a shortcoming of the default viewer that comes with PDF.js. 'coz as you say saving the file on disk has nothing to do with PDF.js itself. Bare in mind that PDF.js works in older browsers ( IE8 and 9, and even older versions of Opera, Firefox, ... ) so this might drag down the default viewer a bit.
Beside, if you know before hand that you want to save the PDF, surely you can right/Cmd click the link and save the file right away.
Anyhow, if we - Opera - decide to use PDF.js as the default PDF renderer for the Desktop browser, we will roll our own viewer which can use fancy pancy features like: <a href=# download>Save</a>
The code of the benchmark is open source. Go check how it works and by all mean send a pull request. Any improvement there will shift focus where it matters most and help every user of PDF.js ( in Firefox itself and in the various extensions and services built on top of PDF.js ).
The benchmark measures 5x the rendering time of every single page of every single PDF.
The problem with benchmarking the "not popular" PDFs is that they're not available outside of their enterprise/office/design agency etc... But if you have any you can share publicly, please file an issue on the Github repository of PDF.js
Some people mentioned Mozilla' Telemetry. Unfortunately it is too limited for this kind of research as it can only report enum values. Using Telemetry would need some work to get a baseline/reference for each computer and the results would take weeks or months to come back due to the lag between the master version of PDF.js and the one bundled in Firefox.
We compared PDF.js against native viewers. The performance was worse but we can fix this. We already started. For the other things e.g.: rendering quality, color conversions, accessibility, text selection, binary footprint, zoom & scroll, ... PDF.js was on par or better.
When I started to work on JBIG2, it was kind of irritating as you were often one week ahead of me. When I started to make some optimizations I would see a PR from you with the exact same things. :p
It's really nice to contribute to PDF.js. Overall between your work and Opera's contributions the font caching, images decoders and color conversions got significantly faster! And there is still a lot we can do.
Tooting my own horn here, but here's my own little "Minecraft" renderer in Neja, circa 2005 ( http://www.youtube.com/watch?feature=player_detailpage&v... ). Over 4 years before Minecraft, and even then that was nothing new. It was kinda cool for JavaScript, in 2005, but all things considered, it was pretty lame compared to Ken Silverman's voxlap for instance.
The "cool" thing about this demo, was that Canvas was not widespread back then so I generated all the chunky effects on the fly as 24bits BMP image, then made a data: URI and update an IMG tag.
