It is a code maintainence, performance and reuse issue. If you roll your own Paint() code you end up having to rewrite functionality in each paint call and you tend to make your layout logic code rather than data driven. Paint also gets called many times per second, it is easy to blow away performance by making expensive calls on data that rarely changes (like the ConvertANSIToUnicode() call below), the VGUI2 framework is event driven and expensive calls only get made when they need to be.
Writing your own complex paint function because of performance sounds like the catch cry of a premature optimiser and you wouldn't want to be one of those would you? In the past any VGUI2 performance problems we have had have been solved by algorithmic changes (mainly moving from a polling model that Paint() enables to an event driven model) and not by optmising individual lines of code. - Alfred John Sheu wrote: > Reviving an old thread of a month ago since I'm still not certain what > the implications are. > > So exactly why is it better to avoid complex Paint() methods? > Methinks > that eventually down the line, the vgui::ISurface calls are still > being > made, so it would make little difference that it is being called here. > Besides, there's gotta be some overhead involved in complicating the > hierarchy even more. > > John Sheu > > On Thu, 2006-03-30 at 11:00 -0800, Alfred Reynolds wrote: >> The third arg to ConvertANSIToUnicode() is the size of the output >> buffer in bytes. In this case you should use sizeof(unicode). >> >> This kind of code is the wrong pattern for VGUI2. It will perform >> really badly (because of the expensive operations you are running >> every time you paint) and makes your layout really fragile. A better >> model is to use a label to contain the text you want to draw and use >> an event to update text. The position, size and font the label uses >> should be contained in a .res file that is loaded by the base frame >> that owns the label ( it looks like CBBHudTaskList should be a frame >> in your case). If you cannot implement an event driven method then >> at least use the >>>> OnTick() method and only change the label text if the state >>>> changes. >> You can use the ::SetText() label call to set the string to render, >> and you don't need to do the unicode translation manually then. >> >> - Alfred > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
