You can clone with
HTTPS or Subversion.
Some applications may benefit from reusing the same viewport and DB range over several frames so the cost of culling or DB decomposition is amortized over frames. Chaging the load balance at every frame precludes these sort of optimizations.
Ignoring range updates in DB modes is relatively easy, but it becomes harder for viewports because they also involve the projection matrices (an overriding what Equalizer already provides makes no sense).
The feature to implement could be to avoid load balancing changes that imply a small change in total pixel area for 2D or range intervals in DB, where the definition of "small" is an application provided hint (could be a config flag)
load_equalizer # adapt 2D tiling or DB range of children
resistance [ x y ] # 2D tile minimum change (pixels)
resistance float # DB minimum change
ConfigParams hint for auto-config?
How about similar API as for freezeLoadbalancing? To be able to change the resistance values during runtime (via the view class). For instance, you might want to lower the resistance value if your are closer with the camera to the model and vice versa.
Add loader support & implementation in tree_ and load_equalizer for #186
On the bike I was thinking about factoring out the LoadEqualizer data part into fabric, and putting this into ConfigParams or View to set these parameters.
Will go for Equalizer base class in fabric containing data & operations for all equalizer types. This is then be used by View and ConfigParams.
Please add file format to https://github.com/Eyescale/equalizergraphics.com/blob/master/documents/design/fileFormat.shtml spec to close bug.
Add load_equalizer resistance feature (Eyescale/Equalizer#186)