A standard method of dealing with this problem is to build your display logic up so that it uses system memory for your user window images. Then use a screen sized buffer, also in system memory that holds a real time copy of what you want on the display. Then at appropriate times when the internal buffer has been modified then copy the internal system memory buffer out to the display controller's memory using tightly optimized code to transfer the image to the screen as fast as possible.

Some things to consider.
1) The above scheme is recommended because in almost all cases the code to do read-modify-write type cycles to the system RAM buffer is way way faster than trying to do that at the display controller interface. Some display controllers are actually configured such that they are write only anyway or operate very slowly if trying to do read-merge-write type operations.

2) Even if some display controllers have certain types of region scrolling capability or rudimentary window support it is almost always the case that these capabilities do not fit to the needs of a GUI type interface requirements where you want the design to drive the implementation rather than the other way around.

3) One way to support a reasonable windowing system is to keep the GUI design strictly hierarchical and each time you create an overlay display area first push the image space under the overlay into a side buffer stack and then pop-it back into place upon removing the overlay. This scheme does require some amount of RAM for it to work effectively.

Michael Karas