diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2022-05-23 21:43:43 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2022-05-23 22:53:47 -0700 |
commit | 4268d43b2dac01c354409a0d5dbbbe903d6e28d0 (patch) | |
tree | 4ae509c12eed32bd55eec8f130930ccff8467340 /Makefile.am | |
parent | c1fed8c508dd89c86de7dd647de0d014c441344e (diff) |
til: simplify fragment->cleared maintenance
Just assume a fragment has been logically cleared after
til_module_render() has done all its potential steps.
I'm not certain this doesn't break some existing assumptions WRT
fragmented/threaded clears and their propagation out to the outer
frame.
But I've been operating under the assumption that this was
already happening in terms of an implicit setting of
til_fb_fragment_t.cleared after a module's render happened.
Except I don't see anything in the existing code or history
actually doing that, which is odd.
For modules that don't invoke til_fb_fragment_clear() explicitly
because they are frame-fillers (think submit, swab, ray, julia,
plasma, these are all full-frame renders that don't benefit from
pre-clearing), they weren't leaving fragment->cleared set,
despite having fully initialized the frame's contents.
We should be able to just assume after prepare/render/finish has
happened for a given module, the target fragment has been
cleared.
Commit 4e5286 had introduced somewhat complicated .cleared
maintenance and propagation for threaded renders, but when we
just treat all finished module renders into a given fragment as
logically clearing the fragment we can just skip all that.
Diffstat (limited to 'Makefile.am')
0 files changed, 0 insertions, 0 deletions