Refactor to clearly differentiate between "interaction handler" events and "camera mutation" events

[lucaswoj]

Some interaction handlers fire events that are named as if they originate the Camera rather than the interaction handler. The separation between these two types of events should be explicit.

• make DragPanInteraction fire dragpanstart and dragpanend instead of movestart and moveend
• make DragRotateInteraction fire dragrotatestart and dragrotateend instead of rotate, move, rotatestart, movestart, rotateend, moveend
• ensure camera fires {pitch, rotate, move} x {*, *start, *end} events itself whenever appropriate
• prevent interaction handlers with inertia from firing multiple moveend events within an individual interaction

Related to #3068 #2792

[mourner]

Can you clarify a bit? The two items above seem unrelated to the issue title — which events would you consider "interaction handler" and which "camera mutation"?

[lucaswoj]

I would consider all the above events to represent "camera mutations" not "interaction handler" events. Those events should be fired by Camera exclusively.

• BoxZoomInteraction fires boxzoomstart and boxzoomend events. 👍
• Camera fires movestart and moveend 👍
• DragPanInteraction also fires movestart and moveend 🙅‍♂️ It should fire events called dragpanstart and dragpanend

I updated the original ticket to be more explicit about next actions.

[mourner]

Agreed, thanks for clearing this up.

[pke]

Is this being worked on? Having a list update while pinch zooming is in progress is really slow, despite using the moveend event.

[mollymerp]

@pke adding this to my list of eventing chores here #4253 😅