Skip to content
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

Dragging is very slow on touch screens #373

Open
xsegrity opened this issue May 8, 2016 · 1 comment
Open

Dragging is very slow on touch screens #373

xsegrity opened this issue May 8, 2016 · 1 comment

Comments

@xsegrity
Copy link

xsegrity commented May 8, 2016

I was having an issue with very slow dragging on touch screens (unusable really). The reason it turns out was the .gu-hide css selector in the default stylesheet uses 'display:none' which caused a reflow/repaint on every incremental move operation. To fix, I changed the css in .gu-hide from 'display:none' to 'left:-9999px'. By keeping the element visible and simply moving it off the screen it didn't cause the reflow/repaint and drag performance went back to normal.

On really simple drag elements (like in your demo) this doesn't cause any issues but if you have a moderately complex drag element then the thrashing ensues. I also didn't have an issue on desktops but that is because they are really powerful and process this whole cycle much faster. It was just on touch screens (latest gen iPad and iPhone6 to be specific) where it became unusable.

I don't know if this would be an acceptable change to the default css or not but I figured I would post here in case someone else is having the issue they could at least do an issue search and see what I did about it.

I also noticed a potential performance boost for people who have moderately complex 'accepts' option logic. In the drag function you call the getElementBehindPoint function (this is what applies the .gu-hide class in order to see what is behind the mirror element). After that the drag function calls findDropTarget, which in turn calls the users 'accepts' function if they have one specified. If this function happens to perform a lot of logic this can also be a source of performance woes. If you simply store off the elementBehindCursor var (e.g. _lastElementBehindCursor) and then only do the findDropTarget operation if it has changed it would also speed things up quite a bit.

I don't know if this would cause other issues or not and in my case I simply made my accepts function faster but it might help someone else with these types of issues.

Anyway, hope that helps. Sorry for the freaking essay.

@TapBoxTech
Copy link

TapBoxTech commented Dec 15, 2016

Fantastic. You saved my @ss. This should get greater consideration.

Actually, I tried visibility:hidden with better results. For some reason left:-9999px was smoother than visibility:hidden, but resulted in no drop-ability, possibly a quirk in my code somewhere. But like you said, display:none is totally unusable.

Thanks for the freaking essay :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants