Once I had an idea of a kind of class which would provide code executed at the Draw() call. The idea come from another idea to create a merge-able canvas.
When hadding files with canvases, new cycles are created, which make sense as the canvas may contain objects (like fits or lines) which are not merge-able. But what about if we can create just one canvas, with histograms which are merged, and then call a code which redo fitting and all other magic?
I cloned your repository and ran your example. I noticed that you’re manipulating the list of primitives, but I’m not entirely clear on the purpose of the TLazyPrimitive class. Could you explain why this class is necessary and what additional value it provides compared to directly accessing the list of primitives? I feel like I might be missing something important here.
Hi @couet. My idea with TLazyPrimitive is to delay the canvas manipulation to the time when is drawn next time. Like, I want to have timestamp on when the canvas was last drawn. Maybe stupid example but I’m sure there will be other use case. Thus the object must store a functor object which will be executed on the Draw() time.
I was thinking about a such object in the context of perhaps extending functionality of hadd. As per current default behaviour, if the N files contain a histogram and a canvas, all histograms will be add together, but all canvases will have its own copy in the output file.
With TLazyPrimitive it would be technically possible to end up with only one canvas which will redraw it contents (using summed up histograms) an the next use (thus TLazy… like lazy evaluation concept…).
There could be a decision branch for hadd which would be completely backward compatible that, if (and there are some but not all of propositions for triggers):
the canvas contains at least on TLazyPrimitive object, or
the canvas contains only TLazyPrimitive object, or
the canvas contains only one primitive and it is a TLazyPrimitive object, then
There is only one canvas object in the output file. I think many people could be happy with a such feature.
About the implementation, it is just prototype. If you think it would be worth working on it, we could just use this repository to develop final product which later could be integrated into root.
Oh, I wasn’t aware of TExec and it seems being similar. However it only accepts strings with macros. My proposition accept functors objects. I’m not sure whether macro in TExec allows for all the same what native code allows.