Sometimes the idea to push the data behind the "window" into a side buffer stack will become impractical. Several things that can render this as a not usable method are:

1) Your user interface GUI is not 100% hierarchical. This means you want to try to bring underlying windows "to the front" without first removing the Window that was on top. In the strict hierarchical scheme all windows are removed in the exact opposite order that they were created.

2) You are trying to fix it so that the you can move the window that has the focus around on the screen.

3) You want underlying windows to be able to update their graphics in real time whilst the topmost focus window is in use. This includes wanting the underlying window to modify the part of its image that is under the current windows that are stacked on top of it.

I mentioned this before but to be able to maintain an environment that has any of the attributes that break a strictly hierarchical structure it is generally required to maintain a virtual graphics image for each "window" with a separate memory buffer for each. You then maintain a linked list of information that controls the Window order and associated control information for each window (size, position, virtual buffer pointer etc). Recreating the full real time screen image involves walking down this list and "painting" into the real time display buffer from each virtual window buffer in its turn. Performance in a system like this depends a lot on how efficient you are able to code the bit image transfer operations and using clever algorithms that only decide to copy the parts of virtual image buffers that are actually visible on the real time image buffer.

In PC type display systems where the display controller memory is pretty much mapped into the memory address space of the host processor then it is feasible to use the controller memory directly as the real time full screen image memory. That also requires, as I mentioned before, an efficient means to support read-merge-write operations into the real time image where edges of the images being copied in do not match match to even byte boundaries of the main buffer memory. Efficient algorithms for this really do require efficient random access addressing into the buffers.

Many simple display controllers just do not support this type of interface. They will have an I/O port type interface with an internal image pointer register that is able to increment or decrement on each transfer of a byte into the display controller memory. Random access within the display controller memory requires separate commands to change this pointer register on the fly to different areas. If the nature of your usage model with the display controller means that you end up spending as many or more cycles changing this pointer register as you do actually transferring image data to the controller then you know it is time to move the real time image buffer to main system memory. Then you can concentrate at preparing an efficient routine that operates in write only mode to the display controller to transfer the full screen image with minimal need to update the pointer register.

Some display controllers do have the ability to cause the above mentioned pointer register to only increment on write operations whilst the increment can be inhibited on read operations. This can be used to advantage if you do decide to try to use the display controller memory as your real time image buffer. Obviously the display interface _must_ support read and write access. It is also highly desirable, if trying to do this, that the interface to the display be parallel in nature instead of a serial type such as SPI or I²C interface to the display.

You also never mentioned what type of processor architecture that you are using here. If the display has more than a nominal 1->2K byte or so of display memory then it becomes questionable if an 8051 type MCU is the correct thing to use. ARM controllers that let you add a high density RAM that appears directly in the processor address space will be your ticket to supporting a display interface that updates fast with reasonable software algorithms.

Michael Karas