RE: [ocemp-devel] Rendering models for OcempGUI

[Benjamin O. <bo...@ve...>]

Marcus,

I need a little better understanding of how OcempGUI draws things. As I
understand it, under the current model, and with *both* proposed models,
any widget is still a Sprite at heart. Thus it can be imported on its
own (say, from ocempgui.widgets import button) and used without any
other pieces of OcempGUI. A Button could simply be added to a custom
sprite group and it would function like any other sprite, even without
all the rest of the ocempgui pieces.

If either proposed models changes that, then I strongly vote against it.
However I don't think they do, as everything will still inherit from
Sprite.

Second, I'm not sure exactly where the inefficiency of the current model
is. Maybe some examples would help me understand:

If I have a HFrame with 20 Label children, and I update 5 of them, does
the HFrame get redrawn for *each* dirty child widget? So effectively, I
want to update the surfaces of 5 widgets, and instead I do 10 updates?
So if that HFrame is in a Table, and I update 5 children, then I have to
do 15 updates?

If that's what the current model is, then I can see how that is very
inefficient. I have a solution that might work, but I'm honestly not
sure if it fits in the sprite-based model or the partial updates model
(or neither).

Every container class can keep two surfaces: its active surface, and its
"pure" background surface. The background surface only needs to be drawn
when the container is created and when its attributes change, and is
simply the surface as if it had no children. The container also keeps a
Sprite Group (RenderLayer or RenderUpdates, whatever) of its children.
Then when a child widget is marked dirty, it clears and draws with only
the parent surface, instead of passing the info up the chain:
MyGroup.clear(parent.surface, parent.background)
MyGroup.draw(parent.surface)

Because "clear" and "draw" *only* affect the areas where the sprite rect
is, it's more efficient than redrawing the whole surface of the
container. Then instead of passing rect info up the chain to the
Renderer, the child simply marks the parent as dirty. If 5 children of a
container change at the same time, the parent container is just marked
dirty 5 times. This continues up the chain until it reaches the
top-level container attached to the Renderer. Then the Renderer picks up
the top-level container, and blits its surface to the screen.

Thus, every update to a child only affects the layer above it.

The problem I see to this is that you might make the child surface
larger than the parent surface, and the parent won't know it (and expand
to fit) until it is time to draw. This is the same problem I had with
the ScrolledList in the chat program, so maybe this isn't such a good
solution after all.

Perhaps you could only force the parent to redraw itself if it detects a
child blitting out of its own surface range. I'm not sure how
complicated that would be.

I'll stop now because this is already longer than I expected and I still
want to respond to David Keeney.

Ben