|
|
|
|
|
|
by c-smile
2236 days ago
|
|
|
That's not anyhow different from typical GDI, CoreGraphics, GTK/Cairo way of doing rendering. Windows, MacOS and GTK maintain internal pixmap buffer for a window. And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update. Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be faster and more flexible. All that UI can be rendered by just 2..3 functions FillRect, DrawText, MeasureText. |
|
|
With dirty rectangles, it's the application's responsibility to minimize much of its drawing; the renderer will at best avoid copying bits where the target of the bits lies outside the drawing rectangle. The renderer can only optimize in situations where the entire call is understood as a full primitive, and it knows that the result will lie outside the dirty rectangle.
With rxi's approach, the application gets to define the commands which update the UI - which may be as complex as desired, as long as they have a calculable rectangle - and the cost of calculating that rendering can be skipped, without needing to query for dirty rectangles or doing any application-side conditional logic, beyond the layer that rxi wrote.
It's particularly powerful if the rendering primitives are higher level than those provided by the native APIs.