From: Ben Olsen <bolsen@ve...> - 2006-01-30 23:28:11
This is great news, Marcus. Sounds like the new system will be much
easier to use, in addition to rendering faster. Looks like I'll have to
take some time off from World of Warcraft to try these out.
> -----Original Message-----
> From: ocemp-devel-admin@... [mailto:ocemp-devel-
> admin@...] On Behalf Of Marcus von Appen
> Sent: Monday, January 30, 2006 4:17 PM
> To: Ocemp-devel
> Subject: [ocemp-devel] New OcempGUI rendering model
> it's been quite some time since the last mail about that task and I am
> happy to tell you, that the first parts are done. After comparing a
> sprite-based model with a self made one (which I'll explain beneath) I
> decided to implement the latter as it does not contain so much
> yet offering all advantages of the sprite-based system.
> What has been done so far? The BaseWidget class was enhanced by a
> draw_bg() method (calling Style.draw_WIDGETTYPE()), which creates the
> visible background of a widget on which the widget's contents (or
> children) will be blitted. The background is stored internally to
> fast update and clearing operations, if only parts of the widget need
> be updated (thanks for the idea Ben).
> The draw() method of the widget now blits the children of the widget
> and/or performs any special operations which need internal information
> of the widget (such as the real caret position on the Entry).
> Both methods are used by the redesigned update() method, which now
> receive additional kwargs to allow finer grained updates of the
> In the current state, it usually receives and checks for a 'children'
> dictionary and a 'resize' boolean.
> The first is used to determine, which parts of the widget need to be
> updated, while 'resize' should cause the widget to do a _full_ update
> and redrawing instead of blitting only the children on its surface.
> Afterwards the update method tries to invoke its parent's update()
> method (be it either a widget or the Renderer), which will do the same
> task again with the caller as child and so on.
> When the topmost widget of that list is reached, it will call the
> Renderer.update() method, which instantly will update the desired
> area. Thus there won't by any delays anymore caused of time-bound
> update loops.
> Widgets also will create all their internals on creation time, so that
> all their information (such as sizes and the rect) can be accessed
> without adding them to the Renderer or enforcing a manual drawing
> To make the programmer's life easier, widgets will make their _rect
> attributes publicly available, so that you now can use widget.topleft,
> widget.center ... as well (as if you would operate with a
> Although several critical parts are still unfinished (such as a full
> z-axis support) the current code works fine and outperforms 0.1.x by
> around 2 to N times, dependant on the amount and complexity of
> Also not all widgets are changed to that new model, but I think that
> I'll be finished with that at the end of the week to offer you a patch
> set for comments and feedback.