View Single Post
Old 07-15-2009, 04:32 PM   #17
Peter Sorotokin
speaking for myself
Peter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it isPeter Sorotokin knows what time it is
 
Posts: 139
Karma: 2166
Join Date: Feb 2008
Location: San Francisco Bay Area
Device: PRS-505
Quote:
Originally Posted by kovidgoyal View Post
Interesting, so rendering happens in page blocks?
Th limit is there because we cannot paginate the content starting from the beginning of the chapter fast enough if someone navigates to the end of the chapter (e.g. through TOC). But if we have some known page breaks in the chapter we can start from those. If the chapter is too long, we just insert them heuristically (in future we may start paying attention to page-break CSS properties). In some sense it is the same startegy that converters have to do, but done on the device itself - and the artifacts are the same (artificial page breaks). Still, it's better than dropping CSS altogether IMHO.

Important consideration here is that XML parsing and CSS cascade can be done fast enough even for very large chapters (although we have not squeezed everything there by any means). Layout and rendering are much slower part. However rendering only needs to be done for a single page, so it is almost always layout which causes the most problems when navigating in the middle of the chapter. (Sequential reading performance considerations are different).
Peter Sorotokin is offline   Reply With Quote