![]() |
Ansel 0.0
A darktable fork - bloat + design vision
|
Everything the two process() paths need, settled once per commit_params(). More...
Collaboration diagram for dt_iop_gamma_data_t:Data Fields | |
| dt_iop_gamma_mask_preview_t | preview |
| gboolean | false_color |
Everything the two process() paths need, settled once per commit_params().
Display encoding is the LAST node of every darkroom frame, so whatever it reads is paid at the frame rate, on every interaction. All of this describes the mask-preview checkerboard and the false-colour channel display, and every field of it used to be read from conf inside process()/process_cl() – six of them through dt_conf_get_float(), which runs dt_calculator_solve() over the stored string on EVERY call: an expression parser, per value, per frame, for a checkerboard an ordinary frame never draws.
Reading application-level configuration is not a pipeline filter's job in the first place. commit_params() is where a node's effective contract is settled, and iop/colorbalancergb.c already settles these same keys there; this module is the other half of the same preview and had simply never been moved.
What makes that safe is runtime_data_hash() (iop/iop_api.h): it folds the first piece->data_size bytes into the cache key, so a settled value that changes re-keys this node instead of being silently served from a cacheline that no longer describes it. The struct therefore holds CONTENT only and no pointers at all – see the api doc for why a pointer in the hashed prefix is wrong in both directions (issue #1145).
preview.width is the ROI's, not a setting: it stays 0 here and is filled per call.
| dt_iop_gamma_mask_preview_t dt_iop_gamma_data_t::preview |