<p>In the olden days of text-mode terminals, the "frame buffer" was a buffer of text, not an image. Scrolling worked in the way you described. The buffer was larger than would fit on the screen, and to "scroll" it would change an offset in the display controller, so it would display different lines. This only makes sense when the whole framebuffer is scrolled at once, which never happens in a windowing system.</p>

<p>Nowadays, it depends on the application. A word processor will rasterise the text separately each frame: there's no off-screen buffer at all. It wouldn't make sense to store an image of the whole document, because the memory use would be huge, and the whole thing would have to be recreated every time the text changed.</p>

<p>On the other hand, an image editor will probably store the whole image, possibly as a texture in GPU memory. A program on the GPU copies the visible section of the image to the application's frame buffer, each frame. This can be done by simply having the view parameters (offset and zoom level) as uniforms and updating them as the view is changed. This is actually very fast even though it's essentially a copy, because GPUs are good at drawing textures efficiently.</p>

<p>A web browser might use either technique, or something more sophisticated. There was a trend in mobile browsers a couple of years ago to render in tiles. The structure of the page would be rasterised to a set of off-screen tiles: enough to more than cover the screen. A program on the GPU draws all the visible tiles into the correct place in the application's framebuffer, clipping the edges. That way, small scrolls or zooms can be performed by changing the offsets of the tiles, without having to rasterise the page again. When you scroll too close to the edge of the tiles, a new row of tiles can be rasterised in a separate thread.</p>

<p>This tile approach is fast to display, uses a fixed number of fixed-size textures, and allows a trade-off between responsiveness and scroll speed. It also allows lower-resolution tiles to be used if the page is too slow to rasterise during a fast scroll. It does require a lot more sophistication in the way you rasterise the page to the tiles, to know which parts of the page can affect which tiles.</p>

<p>Whichever technique the application uses for managing off-screen content, it's responsible itself for producing a new frame each time. The windowing system or compositor doesn't give it a way to specify a window of a larger texture to use without copying.</p>

CC BY-SA 3.0
2018-04-04T10:08:37.103Z
2018-04-04T10:08:37.103Z
Dan Hulme
<p>What actually happens inside computer when the text, pdf, jpeg, ms-word or any other document(file) is scrolled? Does it generate a new bitmap image sufficient for the screen to display even for tiny scroll or are does it show part of bit map image for each scroll? Please describe what is the basic idea behind the working of scroll in laymen terms? </p>

<opengl><rendering><shader><webgl><gui>
What actually happens in frame buffer when an image or document is scrolled?
Charan K
# What actually happens in frame buffer when an image or document is scrolled?

(Asked by: username_0 on 2018-04-03)

What actually happens inside computer when the text, pdf, jpeg, ms-word or any other document(file) is scrolled? Does it generate a new bitmap image sufficient for the screen to display even for tiny scroll or are does it show part of bit map image for each scroll? Please describe what is the basic idea behind the working of scroll in laymen terms?

**Tags:** opengl, rendering, shader, webgl, gui


---

## 1 answers

### Answer by username_1 on 2018-04-04. Score: 6

In the olden days of text-mode terminals, the "frame buffer" was a buffer of text, not an image. Scrolling worked in the way you described. The buffer was larger than would fit on the screen, and to "scroll" it would change an offset in the display controller, so it would display different lines. This only makes sense when the whole framebuffer is scrolled at once, which never happens in a windowing system.

Nowadays, it depends on the application. A word processor will rasterise the text separately each frame: there's no off-screen buffer at all. It wouldn't make sense to store an image of the whole document, because the memory use would be huge, and the whole thing would have to be recreated every time the text changed.

On the other hand, an image editor will probably store the whole image, possibly as a texture in GPU memory. A program on the GPU copies the visible section of the image to the application's frame buffer, each frame. This can be done by simply having the view parameters (offset and zoom level) as uniforms and updating them as the view is changed. This is actually very fast even though it's essentially a copy, because GPUs are good at drawing textures efficiently.

A web browser might use either technique, or something more sophisticated. There was a trend in mobile browsers a couple of years ago to render in tiles. The structure of the page would be rasterised to a set of off-screen tiles: enough to more than cover the screen. A program on the GPU draws all the visible tiles into the correct place in the application's framebuffer, clipping the edges. That way, small scrolls or zooms can be performed by changing the offsets of the tiles, without having to rasterise the page again. When you scroll too close to the edge of the tiles, a new row of tiles can be rasterised in a separate thread.

This tile approach is fast to display, uses a fixed number of fixed-size textures, and allows a trade-off between responsiveness and scroll speed. It also allows lower-resolution tiles to be used if the page is too slow to rasterise during a fast scroll. It does require a lot more sophistication in the way you rasterise the page to the tiles, to know which parts of the page can affect which tiles.

Whichever technique the application uses for managing off-screen content, it's responsible itself for producing a new frame each time. The windowing system or compositor doesn't give it a way to specify a window of a larger texture to use without copying.


---

