Between now and July 1st Caffeinated will become independent of the Google Reader service and moved over to be a completely independent feed reader, free from any third party API.

You get the same great user interface and reading experience you have always known, just without the limitation of a third party API.

This is my current plan forward, watch this space for further developments.

Caffeinated’s article list utilises an NSTableView, but not your standard NSTableView. It has been subclassed and modified until Apple’s default code only really helps with the cell frame calculations, the drawing however is all done within this new instantly bastardised CaffTableView.

The tableview is redrawn every single time someone scrolls, move 1px, it will redraw, so the datasource and the drawing has to be lightning fast. The problem I first had, were the cells within Caffeinated’s list are variable heights, each time the tableview asked for a height I would have to calculate it out and return it, this was not a fast result. This causes serious lag as my cells are rather complex and computing the height on them was a slow task as you would have to word out the bounds of the cell and how the content would draw inside them and adjust the height accordingly.

Luckily, as any good datasource has, each row within the list has a associating NSManagedObject behind it, which vastly helped. As I could easily add a new property to this object store the calculated row height against it. Simple. If the item has a height, give that back to the tableview instead of calculating it again. Problem solved – not quite. With this in mind, you have to clear these values when ever the user resizes the tableview, or the cells will happily draw all out of place.

This method made scrolling rather smooth, but coming from iOS, it just was not smooth enough. I reverse engineered how the tableview works, simply put, every-time it redraws, it will grab all visible cells in view and draw those into the current graphics context. If you have complex cells ( which Caffeinated’s are ), this is one hell of a drawing routine to do.

To overcome this large drawing routine – I cache the cells being drawn. I created a custom cell which must be subclassed when drawing and override some special methods I created, this basically creates an image, draws the cell into the image and caches it against the cell. I created various methods inside the tableview that invokes these cells to cache there images and when drawn, it will use the cache instead of redrawing the cell. So we could of gone from 1000+ ( bezierpaths, shadows, font rendering etc ) drawing routines, down to the number of rows in the table view. Great!, this is now really getting smooth ( around 30 max instead of 1000, this was huge! ).

I wont go into great detail what these methods do to work out what to cache, but simply put, it works out what cells are on the screen and adds the previous and next cells onto those and caches those. When scrolling, its running a routine of clearing out the cached cells that are no longer needed, this is only done to free up resources ( storing NSImage’s is rather memory hungry ). So its only ever drawing and cached the cells which are visible on the screen, + and – 1.

Doing it this way created a silky smooth tableview, but in doing so also created a huge problem – the tableview grid and selection highlights. For the cells to work, they had to be transparent, which is fine. We can draw these transparent cached images over the top of the tableview. Only until I started to implement this did I realise you cannot have subpixel antialiasing on a transparent background. Yikes! The font and text rendering was horrid. Luckily I managed to write abit of code that made it look a little more pretty ( looks like aliased text rendering, but its not, its a massive cheat, but who will notice? ).

Of course, this method also causes a few other issues. What about the drawing of the cell when its selected or resized? The various methods I added into the tableview to handle caching also handle the recaching of cells that have to be redraw.

Many hours were spent tweaking and improving what I always thought to be, a horrid control that Apple had made. Now, the CaffTableView class over well over 1800 lines of custom implementation – this is not just smooth scrolling, but multi-select, sticky rows and alot more.

I hope this summary of what I did to achieve the tableview which sites happily within Caffeinated is beneficial to someone, if you have any questions or comments, just leave a comment .

Curtis Hard