Where would you expect serious threading?
at the spot in between Makie and MakieLayout. Generally, when plotting multiple graphs in disjunct places, that could be threaded, couldnāt it?
OTOH it might be possible to separate conversion pipeline and actual rendering. Same holds for sliders etc as these might trigger relatively complex recalculations.
Overall it might be clever to move the whole rendering into another thread and offer sync. That way calculations by a non-aware user wonāt run into problems while aware users can use the full capability of own threads and just queuing into the render thread.
My case is rendering 6 different plots with aligned axes. Dragging and zooming did lag last time. Nothing major, but nevertheless an opportunity.
But Makie is fast because it uses the GPU, no? Would you expect to mix threads with GPU parallelism?
Thanks for this amazing work. Looking forward to seeing it merged into Makie.jl. I understand that the repo is separate now just so that you can advance with your ideas without being interrupted by other changes in the AbstractPlotting.jl codebase, is that correct? Iād love to do using AbstractPlotting as a developer or using Makie as a user, and get access to this nice layout features.
Keep on with the great work, and happy celebrations!
Cheers,
Iām not sure whether that will work. Ofc I know it CAN work, but itās a LOT of effort I think. Thatās why I said to do actual rendering in a distinct render thread. The whole pipeline before actually rendering could be parallelized though, I guess.
There is still a lot of optimization potential for interaction with linked axes I think, right now zooming and panning them is pretty slow. Also, the ticks are suboptimal because I was waiting for a fix in AbstractPlotting that allows me to make all ticks one annotation plot instead of 20 text plots. So many text plots make updating the tick marks much slower than it has to be. These things gladly donāt need any threading, so letās see how far we can get that way.