Window Manager Repainting
Posted: Fri Sep 12, 2014 1:39 am
Hello 
I'm currently implementing my window manager (for the second time
). For performance reasons, I don't want to repaint/blit everything on the screen each time it refreshes. I'd like to hear some feedback on the model I came up with, and how you have done this.
Theres a screen class containing the root component. Everything on the screen is a component and has a buffer of its width * height * 4 bytes (ARGB) for the content. Each component has a bool "needsRepaint" that indicates whether the component needs to be repainted. The screen holds a rectangle that contains the absolute invalid area on the screen of what has changed.
Updating:
The root component of the screen is asked to update; this updates itself and tells each child to do the same. Each component may now do animation stuff and the like and decide if it needs to be repainted.
Painting:
The root component of the screen is asked to paint; this paints itself to the buffer if "needsRepaint" is set and then tells each child to do the same. Each component may then use the "invalidate" method giving the area on itself that must be copied to the graphics buffer to its parent, which does the same recursively until the screen is reached. The screen then adds this area to it's invalid rectangle.
Blitting:
The buffers of all components are recursively added to the screen buffer.
Posting:
The area that is marked as invalid on the screen is converted to the output graphics format and copied to the buffer of the graphics driver.
For illustration purposes, this is pseudocode of how the two basic classes look like:
What do you think about this?
Greets, Max
I'm currently implementing my window manager (for the second time
). For performance reasons, I don't want to repaint/blit everything on the screen each time it refreshes. I'd like to hear some feedback on the model I came up with, and how you have done this.Theres a screen class containing the root component. Everything on the screen is a component and has a buffer of its width * height * 4 bytes (ARGB) for the content. Each component has a bool "needsRepaint" that indicates whether the component needs to be repainted. The screen holds a rectangle that contains the absolute invalid area on the screen of what has changed.
Updating:
The root component of the screen is asked to update; this updates itself and tells each child to do the same. Each component may now do animation stuff and the like and decide if it needs to be repainted.
Painting:
The root component of the screen is asked to paint; this paints itself to the buffer if "needsRepaint" is set and then tells each child to do the same. Each component may then use the "invalidate" method giving the area on itself that must be copied to the graphics buffer to its parent, which does the same recursively until the screen is reached. The screen then adds this area to it's invalid rectangle.
Blitting:
The buffers of all components are recursively added to the screen buffer.
Posting:
The area that is marked as invalid on the screen is converted to the output graphics format and copied to the buffer of the graphics driver.
For illustration purposes, this is pseudocode of how the two basic classes look like:
Code: Select all
class Screen {
Rectangle invalid;
}
class Component {
Component* parent;
list children;
bool needsRepaint;
void update();
void paint();
void invalidate(Rectangle r);
}Greets, Max
) I would suggest to implement an abstraction layer between the actual window manager and the apps. It isn't nice to do putpixel(x,y,r,g,b,a) for every pixel, or even something like paintstar(x,y,w,h,r,g,b,a) isn't always the best. If not in raw draw mode, the apps must have a general way to "make a window", or else they could make all sorts of strange things (though thats not a bad idea 
)
