Not necessarily. Could be that the load on the instance is lower at the moment, and updating your original notebook would have yielded the same result (note: cell content or positions need to change for the thumbnail to update).
The actual timeout appears to be somewhere around the 12s mark. I’ve created two notebooks to test thumbnail generation for:
- a single image, moved bottom to top with increasing delays,
- multiple images, created bottom to top with increasing delays.
The tumbnails and notebooks can be reviewed here:
Apologies for the late reply. Enjoyed a couple of busy days.
Thanks for this nice approach to test this. And yes, I can see the 12s mark.
Then again, I cannot imagine that my little notebook takes more than 12s to render, not even on the thumbnailer.
When I time it, it’s under 2ms.
If you take a look at my overview page on https://beta.observablehq.com/@martien and zoom in using your browser, you can see in the footer of Flower—a simple fork of Flower (old)— a render time in ms of 0, 1, 2 max.
Flower (old) fails to show a thumbnail, despite being the same code. I cannot figure out why that may be.
Puzzled as ever
Your timing only accounts for the evalutation of the
show function. You’ll want to start your timer from the moment the notebook loads: https://beta.observablehq.com/compare/64effbd662037e97...8156160658b490e0
In the case of my fork the thumbnail generated without problems. Try adding a whitespace somewhere in your “Flower (old)” notebook and check the thumbnail again. I’m fairly certain it will generate properly right now.
How do you mean, “add white space”? In the code? In the chart?
My experience is similar to yours. When I forked Flower, it renders the thumbnail correctly.
In any cell. It’s just to change the notebook content and force a new thumbnail to be generated.
From what I’ve gathered it really for the most part depends on external factors, like overall load on the server that’s responsible for thumbnail generation, and response times from external sources (e.g. unpkg.com).
Ah, clear. Thanks.
Re unpkg, I assume that’s run under the hood. Is it run for the notebook itself, too? How does the revision history influence the unpkg time?
As far as I can tell there’s really nothing special going on. The headless Chrome instance just accesses notebooks like you in your browser would. The only difference is the URL it uses, which seems to render just the notebook without any Observable UI.
I also still don’t believe that the revision history affects the load time. Again, try changing your notebook content (so that its hash changes) to force a new revision, and in turn force the thumbnail to be regenerated.
I’ve tried forcing regeneration repeatedly, without success.
I’ll let it go for now. Thanks for your lasting support.
As far as I can tell forks keep the revision history. Would you humor me and republish Flower (old) so that its update date (mouseover on publish date) shows today?
I just humoured you.
Thanks! And again, a fork’s thumbnail appears almost immediately. …
- Thumbnail for https://beta.observablehq.com/@martien/flower does not generate despite multiple updates,
- thumbnails for vanilla forks of the notebook generate almost immediately.
Thanks for all your effort and raising the attention.
Thanks everyone for the investigation! The gist is, well: right now we generate thumbnails on ‘cloud’ infrastructure (basically, Heroku), with puppeteer. It’s sub-optimal and we’re doubtful it can get that much better without a categorical shift: specifically, doing thumbnails on hardware - preferably a shiny Mac Mini. That’s pretty high on our list, but we’ve got a few things to ship before we tackle it. Thanks for your patience in the meantime.
I think this might be a bug not in how we generate thumbnails but how we schedule them. I’m not going to dive into the details in this thread, but I have a hunch as to what’s going on and it should be easy to fix.
I fixed a bug in the thumbnailer, and @Martien’s flower is blooming again.
Woohoo! This fixed all my notebooks as well!
For the moment, it uses @mootari’s trick
thumbnail_daemon = navigator.userAgent.match('HeadlessChrome')
But that can be changed to some other detection mechanism if the Observable thumbnail daemon ever switches user agent. Then notebooks relying on it won’t have to be manually changed one by one if it ever breaks.
Maybe the Observable team could explicitly add a built-in name, or at least commit to some reliable detection mechanism?
They added a preview image option!