I've read in this forum that someone observed high CPU usage with Activity Monitor when scrolling with Safari...
Sure, because much of the rendering (for instance text, if I am not mistaken ), is done by the CPU. Because scrolling involves lots of content update very quickly, the CPU will get taxed.
I understand that an application window is a view and is a container of several other views such as button, listbox, scrollbar, textarea, canvas,...etc. Every view element has a refresh method that allows it to redraw itself whenever needed. When a window needs to refresh, all its ui elements refresh method is called. The refreshing takes into account the window Z-order in order to optimize it. Also, your desktop is a ui element, a kinda of super container of all your applications' windows.
At the OS level, my understanding is that it uses pools of buffers of the same size that are filled and displayed in a cyclic way.
If your applications' windows contains several non static content, like for instance webpages with animated gifs, and jquery animations,..etc, then only the thread feeding that canvas area is aware of it. I don't see how the OS could detect and delimit those areas... My understanding is that the it takes a continuous snapshot of your display context and displays it... If not when and how the OS technically delimit those areas?
You talk about a model which is used by old Windows GUI
😉 OS X and modern Windows (.NET) work very differently from that, and some really cool stuff is possible.
In OS X, the OS itself is aware of every UI element in your application and the redraw chain is managed by the OS itself. For instance, if a button text in an application has changed, the button will notify the OS that it needs a repaint, and the OS will only invoke the repaint code of the button.
Furthermore, all windows and most controls are rendered into an off-screen buffer. This buffer is then kept. Changes to a window only seldomly require execution of the full repaint chain usually its enough to update only the part of the buffer which has changed. A repaint code of a control does not necessarily redraws everything it is also able to redraw a portion. Also, a control can notify the OS that only part of it has changed. For instance, a well written web browser will detect that the only changed part of the image is the banner, and notify the OS that this small area needs a repaint (this is called a dirty rect). The OS will then call the paint message (method) of the web browser window, restricting the paint area to this dirty rect. This is much more efficient than redrawing everything.
If you want an example of how far this goes, look at how scrollbars are implemented in OS X. There is this nifty control called NSScrollView which implements a window with scroll bars. It would store the already drawn content in a buffer and when the control is scrolled, rather then redrawing everything it will only redraw the new portion (i.e. that which wasn't visible before), and copy the part of the previous image from the buffer. For example, if you scroll half a page up, the NSScrollView will copy the bottom half of the old image which now becomes the upper part of the new image. Only the bottom part of new image has to be rendered.
