Let's take web browsers as an example. On mobile, both Chrome and Firefox draw the page content on the GPU, and they typically have a lot of scrolling, so it's a relevant example.
They work a little like Google Maps or Open Street Map's tileserver. They slice the page up into tiles and draw each tile into a texture. (The textures may well be in a texture atlas; I'm afraid I don't know the specifics.) Drawing the final screen simply consists of drawing a small number of textured squares in the correct positions. This approach makes scrolling very easy.
When you scroll, it doesn't have to regenerate the whole page starting from the DOM (the web page equivalent of the scene graph): it just moves the quads around so that each textured tile moves around the viewport. When a new row or column of tiles is about to come into view, the page renderer has to draw the new tiles before you want to see them. At the other end of the screen, you can keep tiles that are no longer in view, but they can be disposed of if you start to run out of texture memory. Because all the tiles are the same size, you can simply draw the new tiles over old textures you don't want any more.
It's just the same as in Google Maps: when you scroll in that, you can usually see a placeholder texture if new tiles are visible before they've finished downloading. And the page keeps a cache of tiles you've looked at before, but it can destroy any that are no longer visible in order to free some memory if necessary.
The tile technique also allows progressive refinement, which is important to let you scroll at 60 fps on a mobile platform without enough compute power. If it's rendering the tiles too slowly, it can draw the textures at lower resolution first (while you're scrolling), and then redraw them at full resolution later, if they stay on screen.
In short, there isn't any special functionality for blitting some of the last frame into a new position in the new frame, but by rendering to texture, we can access the same texture from the next frame, throwing away any parts that are no longer useful. Some games also use this technique for mostly static content backgrounds, 2D world maps, &c.
If you have to update small portions of the scrolling content, it's easy: just redraw the tiles that changed. The code that updates the tiles doesn't care what screen position they're being displayed, because the final frame renderer puts each tile in the right place. You don't have "two un-synced copies of the canvas" and it doesn't matter whether you're drawing each tile on the CPU or GPU (or both).
The word "static" there was important. If much of the background is changing every frame, you don't get any advantage from tiles, because you have to update every tile every frame. In that case, you should just throw away the old frame and draw the new frame from scratch. That's why many 2D games don't use this technique even if they show scrolling content (e.g. a Mario game).
- If your scrolling content is completely static and small enough to fit in memory, draw it in a big texture and render a textured quad per-frame.
- If your scrolling content is too big to fit in memory, or small regions of it need updating sometimes, draw it in tiles, render all the visible tiles per-frame, and add something to load and unload tiles when necessary.
- If most tiles change most frames, just draw the visible region every frame.
Knowing which case you're in, and being able to separate out the static parts from the changing parts, constitutes a lot of the work of the graphics developer :-)