Tablet is written in Java and is compatible with any Java-enabled system with a runtime level of ≥1.6. We provide installable versions that include everything required to run the application, including a suitable Java runtime. The installers are available for Windows, Mac OS X, Linux and Solaris, in both 32- and 64-bit versions. Once installed and running, Tablet will also monitor our server for new versions and will prompt, download and update quickly and easily whenever a new release is available, along with redirecting the user to a web page describing the new features that have been added.
A prime requisite during development of Tablet has been computing efficiency and speed. The two main approaches to handling assembly data in viewers are either memory-based, where all the data are loaded into memory, or disk-cached, where the data reside on disk with only the currently visible segment of the dataset held in memory. Memory-based applications are faster for viewing and navigation (after an initial delay while loading the data) and can provide whole dataset overviews and statistical summaries, but the size of dataset they can handle is limited by the amount of available memory. In contrast, cache-based applications can display views from much larger datasets using a minimum of memory, but access to the data can be orders of magnitude slower (which then affects navigation and rendering), and the feature sets available are often limited.
With Tablet, we have chosen a hybrid solution that provides us with advantages from both approaches. We hold a ‘skeleton’ layout of the reads in memory, with data on each read limited to just an internal ID, its position against the consensus or reference sequence and its length. The nucleotide data itself (efficiently compressed so it can be read as quickly as possible), along with other supplementary information—such as the read's name and its orientation—is held in an indexed disk-cache and is only accessed (via the read's ID) when required. Tablet also allocates memory on a per-contig basis, including information for features such as how to pack the data for display, coverage calculations, padded-to-unpadded mappings, etc. These data are calculated and stored before each contig is rendered and discarded again after display. This approach allows us to provide maximum functionality—instant access to any portion of the data; extremely fast and high-quality rendering; entire dataset overviews—yet memory usage is kept relatively low.
Comparing data indexing/loading times and memory consumption across a range of tools for an assembly file containing ~2.9 million Illumina Solexa reads of length 51, we found that the cache-based viewers (Maqview, MapView, tview) were fairly constant in memory usage (between 35 MB and 70 MB while viewing), with indexing times varying from 10 s to 50 s, although memory consumption during indexing did peak as high as 350 MB with MapView. For the memory-based viewers, we compared Hawkeye (5500 MB; 107 s), Consed (2600 MB; 73 s) and EagleView (2450 MB; 98 s). Tablet, being a hybrid, loads the data in 25 s, and uses just 175 MB of memory.