-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
draggable point example is slow #2334
Comments
I actually can't even drag the marker... |
It's broken but fixed by #2333 |
As @mcwhittemore points out in #2327, its lagginess depends on how much you're zoomed in. Investigating. |
OK, spent some time investigating this and I found at least two issues that cause most of the lagginess:
The dragging becomes much smoother if you fix both (not one or the other). I'm also convinced that it will get much smoother if mousemove is throttled — should we do this internally for the |
Fixing the second point can also improve Studio responsiveness considerably (cc @samanpwbb), so we should prioritize this. It may be pretty tricky though, considering upcoming DDS changes, after which cascading may be required by paint properties other than |
Even before 1f9029c |
We can improve
|
Isn't the main issue in this example that there are two
Before going deeper on library-level optimizations, let's rewrite the example to have a single |
After that, I'd prioritize things like this:
|
Another thing that would be useful for this example is |
@jfirebaugh yeah, my bad about misunderstanding I also think that we should optimize noop |
|
looking at mapbox gl i was first puzzled by the lack of an easy way to work with markers. i then found the draggable point example which comes close to a marker, but i also get extreme lagging when zoomed into street level on chrome. with firefox zoom level doesn't seem to matter, it's sluggish no matter what, but not extreme. in my opinion, a good user experience requires that placing and dragging markers is very responsive. it should be possible considering how smooth and responsive e.g. map zooming is. |
This is much better now due to improvements in the |
The example is still extremely laggy in Chrome. :( |
Is there work being done to improve dragging responsiveness? I'm working on an application that would benefit from very snappy drag-n-drop interactivity, and my code using mapbox is not quite able to do what I want yet. When I look at the mapbox example page, it's not very fast either, even with the minimal example. The circle still delays behind the mouse more than I'd like. I'm assuming that the problem is due to a pretty fundamental design choice where data layers need to be updated via It's almost like there should be a setting to temporarily give a layer priority rerendering so you can do more tightly interactive animations. Or maybe others have figured out some solutions here? I know Leaflet is completely different on the backend, but here's an example of acceptable dragging performance: |
I haven't looked into the performance recently, but the comment by @livemixlove seems to indicate the problem is still there. There must be a way to make dragging fast. It's basic map interaction and poor performance impacts very negatively on user experience. |
@emiltin , To be clear, I'm guessing that performance has improved since this issue was first created. I would consider the current drag performance to be "OK", but not great. My metric is "slower than leaflet". |
Ended up working around this by overlaying an absolutely positioned seperate canvas on top of the mapbox container with pointer-events off to be used for actively being edited features. So mapbox still handles mouse events and when you edit a shape it moves it to the active canvas and when you stop it saves/moves it back to the mapbox layer data source. Turned out to be less painful than I thought it would be to add some of this, just use map.project(coords) to get screen x,y coordinates and your in business. Though since my issue was with mapbox gl draw I ended up having to rewrite the different draw modes for doing it this way. The problem seemed to be much more noticeable when you have additional large vector or raster layers on top of the base map. Also it's very related to screen resolution. You don't see the lag at all in the tiny little div on the mapbox draw demo but if you copy the code and put it in a full width/height container the lag is noticeable |
mapbox-gl-js version: v0.16.0
Steps to Trigger Behavior
Expected Behavior
It should be fast and smooth.
Actual Behavior
It's slow and choppy.
The text was updated successfully, but these errors were encountered: