3 ms·

> herky-jerky scrolling because the programmers do not understand how to write concurrent display code Yes, PDF readers are bad. What makes the problem worse

> herky-jerky scrolling because the programmers do not understand how to write concurrent display code Yes, PDF readers are bad. What makes the problem worse is that the PDF itself, is sometimes a resource-intensive format as well. Finding information from a modern datasheet is a pain, finding information from a scanned 300 MiB datasheet from the 1980s is real pain. Lots of rendering. None of the problem (other than keyword searching is not available) exists in a physical book, the human brain is a great pattern-recognizing machine. Nothing beats flipping through the pages and using fingers as markers yet...

WalterBright 7y ago
What I mean by concurrent display code is the display of the pdf file is always up-to-date even when the renderer cannot display the data fast enough. The trick is to abandon the current render whenever the position in the file changes, and start a new render. I did this back in the 1970's (!) when I designed and built a 24x80 glass terminal. The 6800 microprocessor simply could not keep up with 9600 baud serial data coming in. So what I did was hook an interrupt handler to the serial port, which stored the incoming characters into a 24*80 circular buffer. The display renderer would start at the beginning of the circular buffer, writing characters to the display buffer. If more characters entered the circular buffer which would invalidate the display, the renderer would simply start over. Whenever the data coming in paused slightly, the display would catch up almost faster than you could see. It worked great! I since incorporated the same idea into the MicroEmacs text editor in the 1980s, meaning the editor display was always crisp and responsive despite running on an 8088. (Other editors would fall behind, and when you took your finger off the auto-repeat page-down key they'd eventually catch up. This behavior is what most PDF readers exhibit.)

WalterBright 7y ago

What I mean by concurrent display code is the display of the pdf file is always up-to-date even when the renderer cannot display the data fast enough. The trick is to abandon the current render whenever the position in the file changes, and start a new render. I did this back in the 1970's (!) when I designed and built a 24x80 glass terminal. The 6800 microprocessor simply could not keep up with 9600 baud serial data coming in. So what I did was hook an interrupt handler to the serial port, which stored the incoming characters into a 24*80 circular buffer. The display renderer would start at the beginning of the circular buffer, writing characters to the display buffer. If more characters entered the circular buffer which would invalidate the display, the renderer would simply start over. Whenever the data coming in paused slightly, the display would catch up almost faster than you could see. It worked great! I since incorporated the same idea into the MicroEmacs text editor in the 1980s, meaning the editor display was always crisp and responsive despite running on an 8088. (Other editors would fall behind, and when you took your finger off the auto-repeat page-down key they'd eventually catch up. This behavior is what most PDF readers exhibit.)