Category: Programming

As a quick diversion, I recently followed Peter Shirley’s excellent Ray Tracing in One Weekend guide, which is a terrific refresher of the surprisingly simple math involved in ray tracing. And in the spirit of Atwood’s Law, I decided to do it in Javascript, since I don’t work with Javascript very often, and thought I could use a refresher in it, as well. The result is some relatively passable Javascript code (which is slow as hell!), but some really pretty pictures:

Some possible future work might be to create a renderer for black holes (in addition to regular spheres) which would actually curve the surrounding space and affect the direction of the rays. This would necessitate a radically more complex ray tracer, which would need to follow the path of the ray in a stepwise fashion using Boyer–Lindquist coordinates within the Kerr metric. Perhaps a project for another weekend (or two)!

As the developer of a relatively popular app, there are numerous things I have to worry about on a regular basis. One of these things, however, is something for which I was kind of unprepared, and still not sure how to deal with: the emergence of knock-off apps – apps that have a suspicious and often hilarious resemblance to the original.

There were, of course, counterfeit apps that were blatantly using my trademark in their name (“DiskDigger” is a registered trademark in the U.S.), or my graphics in their store listings, in which case the Google Play Store thankfully took them down upon request.

But then there are apps that don’t quite use my trademark, and don’t quite have the same icon and screenshots. But because they are close enough, they can take advantage of being near the top search results for this category of apps, and lead numerous unsuspecting users to install them and be greeted with a barrage of ads and spyware.

Most of these apps seem to come from Indian and Middle-Eastern developers, which makes the horribly broken English in their app verbiage even more amusing to read. A small part of me even applauds their enterprising spirit, and I don’t fault them for wanting to make a buck, but I wish they’d find ways of doing it more honestly.

Take a look! Can you tell the knock-off apps from the real ones?

The problem is that because these apps don’t explicitly violate my trademark, Google refuses to take them down, which is unfortunate because these apps do literally nothing except shove ads in the user’s face, and therefore actively harm the ecosystem of the Play Store. Shouldn’t Google care more about preventing the Play Store from becoming a cesspool of bottom-feeding cash grabbers?

In my day job, one of my responsibilities is to oversee the technical evolution of our product  and to optimize its performance. I’ve even written a few guidelines that detail numerous recommendations for maximizing performance of Android apps in general.

One of the things I have always recommended is to reduce the complexity of  View hierarchies, and try not to overcrowd or have too many nesting levels of your Views, since this can supposedly have a negative impact on performance.   However, I made these statements based on common sentiment on the web, and based on the Android  documentation, instead of on actual hard evidence.   So I   looked into it from an interesting perspective:   I dug into View hierarchies  as they are used by other major apps, and compared them with our own usage.   This isn’t a totally “scientific” analysis, and it only looks at a single facet of proper View usage. Nevertheless the findings are rather surprising, and are actually challenging my insistence on View minimalism.

I looked at the Twitter, Facebook, and Slack apps, and compared each of their “feed” screens to the feed screen of our own Wikipedia app. (The reason I chose these apps is that the “performance” of their feeds is nearly perfectly smooth, especially considering that some of their content includes auto-playing videos and animations.)   I used the superbly useful and little-known UI Automator Viewer tool, which is bundled with the Android SDK, to explore these view hierarchies.

For reference, the deepest nesting that I found in the feed of the Wikipedia app is seven (7) levels deep:

But get ready:   The deepest nesting in the Slack app is…  eighteen  (18) levels deep. And yet it performs perfectly smoothly:

The deepest nesting in the Facebook app is  twenty  (20) levels deep. And yet it works just fine:

The deepest nesting in the Twitter app is  twenty three  (23) levels deep, which includes eight (8) nesting levels for each item in their ListView (it’s not even a RecyclerView!). And yet I’m able to scroll the Twitter feed infinitely without a single hiccup.

Therefore I’m compelled to reevaluate the importance we should be placing on  optimizing  View hierarchies, at least from the perspective of “nesting.”   Indeed, this seems to be yet another case for balancing reasonable performance guidelines with more immediate product goals, or put more simply, avoiding  premature  optimization.

When you look at a folder full of pictures, and enable the display of thumbnails in your folders, Windows will show a thumbnail that represents each of the pictures. Creating these thumbnails is an expensive operation  – the system needs to open each file, render the image in memory, and resize it to the desired size of the thumbnail. Therefore, Windows maintains a cache of thumbnails, saved in the following location: [User folder]\AppData\Local\Microsoft\Windows\Explorer.

A few years ago I published a utility for examining the thumbnail cache in Windows Vista and Windows 7.   However, in Windows 8 and Windows 10, Microsoft seems to have made some slight modifications to the file format of the thumbnail cache which was preventing my utility from working properly.   So, I revisited the thumbnail cache on the most recent version of Windows, and made sure the utility works correctly with it, as well as with all previous versions of the cache.

My updated ThumbCacheViewer supports thumbnail cache files from all versions of Windows after XP.   It automatically detects cache files associated with the current user’s account, and it also allows you to explicitly open thumbnail cache files from any other location. Once the file is opened, the utility will show a simple list of all the images contained in the selected cache. If you select an individual image, it will also show some useful metadata about the image:

You can see that the cached images include thumbnails of individual photos, as well as thumbnail representations of folders that contain photos. Both of these can be forensically interesting, since the folder thumbnails still contain plenty of detail in the images. You can also see that there are separate caches for different resolutions of thumbnails, some of which are strikingly high-resolution (up to 2560 pixels wide, which almost defeats the purpose of a cache).

I’ll also point out that you can perform forensic analysis on thumbnail caches using DiskDigger, by opening the cache file as a disk image. You can do this by following these steps:

• Launch DiskDigger, and go to the “Advanced” tab in the drive selection screen.
• In the “Bytes per sector” field, enter “1”.
• Click the “Scan disk image” button, and find the thumbnail cache file that you want to scan.
• Select “Dig deeper” mode, and proceed with the scan.

Here is the same cache file as in the screenshot above, but viewed using DiskDigger (note the numerous .BMP images detected by the scan):

Either way, this is now a relatively complete solution for analyzing thumbnail cache files, whether you’re a professional forensics specialist, or a home user who’s interested in how Windows preserves thumbnails in more ways than you might think!