> Each time we draw a bit of graphical content to a scroll view, we first allocate the tiles necessary to display the corresponding visual area.<p>I get the intent here, to avoid the issue of not knowing how large a buffer to allocate for your scroll view in the first place. But doesn't this still use way too much memory? Especially for something like an irc client, the scroll view will only grow as the program is used longer, and as such the number of tiles of rendered content will also only grow. You'll of course need to keep the textual history in memory, but that's <i>far</i> smaller than the rendered screen contents.<p>Proper GUI toolkits (disclaimer: I have worked with few, and only a little at that) handle this, I think, by not considering the scroll view a canvas to draw stuff on, but instead a thing that you can place <i>widgets</i> on. Each widget has access to some data that allows it to re-draw its graphical content at some position on-screen, and the scroll view forgets rendered content far outside the visible area, and asks widgets to re-draw their content whenever they get scrolled onto the screen again.<p>Of course, you could expect requests for even more over-engineering ;)<p>Cool stuff! As someone else mentioned, you missed April 1st.