I recently got acquainted with Makie and I absolutely love it!
Here are 2 small questions related to zooming (in GLMakie):
Is it possible to update the ticks dynamically when zooming? For instance I would like ticks at 10, 20 and 30 with the default view, but when zooming by x10 I would like ticks at 1, 2 and 3
Is it possible to synchronize zooming on several axes? For instance, I have a stack of 3 axes with the same x axis. When I select a rectangle region in the first one, I would like the x-zoom on the other two to react accordingly.
New ticks appear when I don’t specify the ticks precisely. However, when I need to define ticks manually, they don’t adapt to the zoom level. This is especially problematic for axes with dates, since those are not supported natively.
On the screenshots below, which were generated with
Ok yes if you fix the ticks, they’re fixed If you need different dynamic ticks than the defaults then you can create your own tick finder. This is probably a bit tricky for date ticks, and it will depend on how the numbers that you plot relate to the dates that they represent. You will sometimes see solutions where only date-specific formatters are applied to a non-date-aware tick finder. This then leads to weird tick choices that happen to match the underlying nice integer ticks, like "Sunday 10:50pm", "Wednesday 9:10am" as a made-up example. A real date tick finder would be aware that on a span of weeks you want to see days, on a span of a day you want to see hours, etc. Makie currently internally converts to Float32 precision, which is why we don’t have Date machinery, dates can not be represented faithfully in 32 bit…
Seems obvious when you state it like that You mean I should try to imitate LinearTicks(n), but with dates? Something like LinearDateTicks(min_date, max_date, n)? I can’t seem to find the interface requirements for these tick finders
Hmm I don’t want to canonicalize a “hack”, when we add real Date support it will be integrated better. This solution here depends on the type of conversion from Dates to numbers which will probably not be the same for everyone. But we could think about adding guidance to the docs that I linked until that’s happening.
I understand that this is a hack, and that putting it in the docs may be the best you can do for now.
However, note that according to the Dates documentation, there are only two natural ways to perform conversions between dates/times and numbers, because date/time objects are nothing but number wrappers:
A Date stores the equivalent nb of days
A DateTime stores the equivalent nb of milliseconds
The forward conversion operation is performed by Dates.value in both cases, and the backward operation can be defined thanks to unix2datetime.
So either Makie has to first scale the dates into a range where Float32 is okay, or we need some other mechanism to deal with the precision problems. GLMakie will probably never be able to deal with Float64 though, as I don’t think GPUs like those very much.