Do you see the same behaviour if you use the Chrome browser instead?

In chrome it's not as bad, but there is still considerable lagging while dragging. However my chrome installation, tends to crash quite often (redirect to the "Aw snap" page) with Easyeda, which makes it rather useless (the browser).

Not saying this is the problem but the behaviour you describe is symptomatic of a slow connection to EasyEDA. Are you going through a firewall that could be throttling your connection?

Hi, seems unlikely this is what my connection looks like pt: Download Speed: 113986 kbps (14248.3 KB/sec transfer rate) Upload Speed: 28119 kbps (3514.9 KB/sec transfer rate) Latency: 10 ms Jitter: 7 ms Doesn't seem like the best idea to halt the browser to do server-side checking, while dragging in still progress - if this is what You're saying? I haven't had time to thoroughly analyse what's going on in the browser, but the problem started recently. It does seem to be somewhat influenced by the complexity of the PCB.

Also I have tried this on several computers, with the same result.

OK, so I just took a look in Firebug and I am not seeing any request being made while dragging an object, I've also noticed that the lag is legible on some areas of the PCB while crippling on others - seems dependent mainly on the number of ground/power fills beneath the object being dragged (4 layer PCB).

I'm using a reasonably capable laptop. Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz 16 GB ram.

@Demianaa Your laptop is powerful. Chrome is 2X-5X faster than Firefox in EasyEDA. you can give Chrome a try and look the diffirent. If Chrome is slow too, hope you can share the PCB private to let us to dig the problem You are right, move the vias will run the real time DRC, needs lots of CPU resource. But for your such power full computer, I don't think any problems.

@Dillon Yes it should be powerful enough, maybe I will try Chrome but as I mentioned the problem with Chrome is that it often "crashes" and redirects to the "Aw snap" page - for example when pressing shift+B, it crashes every other time. And after a redirect any unsaved changes are lost.

@Dillon OK, so I tried disabling real-time DRC, but the lagging is just as bad. I have shared the PCB with You with the project-name shared_demianaa. An example of a problematic area is under the RFM69, whereas areas with less going on are OK.

@Demianaa thanks for to share such a nice PCB to me. I test it under I5, 8G under Firefox and Chrome, move the vias are fast enough, SHIFT+B will be slow, but no crash. Will share it private to @Andyfierman , he is a team memeber.

OK, thanks. Strange though, it was working fine for me until recently.

@Demianaa I have tested under lots of computers and lots of OS. All Ok. Now I am worried that I don't under how you move? Is just some vias or every via? Don't need to open firebug, it will make your browser very slow. If we have some images or gif, will help us to reproduce your operation like your way. Your PCB is complex, but under your compouter, it is not any problem, for 6 layers 3,000 pads are our targets

@Demianaa, Hmmm, Does the lag change if you select only the working layer (i.e. hide all the others)? I can see a couple of DRC errors in the Design Manager tab on the POW_BTN net where it is too close to the board outline but that is the only thing I can see that is not quite correct. I have tried moving vias - from under the RFM69 as well as in other places - and, after moving the via, observed have no significant lag (i.e. anything more that a few tenths of a second) between clicking on **Rebuild Copper Area** and the action happening. I have tried this with the Realtime DRC on and off, with different selections of layers made visible and/or active and have tried moving vias into completely nonsensical places as well as just minor adjustments. I have also tried moving groups of vias at the same time with about the same short delay between clicking on **Rebuild Copper Area** and the redrawing action happening. In all cases with the Realtime DRC on, if I move the via(s) into a position where it would cause one, there is no perceptible delay between moving the via(s) and a DRC marker appearing or disappearing if I move the via(s) away from an error position.

@Dillon I only used Firebug to se if it might be a network issue as andyfierman suggested - it's turned of when not in use =) As I mentioned the problem started recently, I only had a similar issues before while dragging many components at once. I can't really screen grab the movement and I don't want to install any screen-capture software just for this. However the issue is easily imagined - the object I'm moving simply doesn't follow the mouse real-time, but jumps into place when I stop moving my cursor for a while.

@andyfierman Not all vias, for example there is a via at: mouse-X -1109; mouse-Y 1240 (mil) - that i kan move around without issue (also gge554 and gge555)... To clarify - it is while i'm dragging the lag occurs, in other words the object doesn't follow my cursor. Also the same issue occurs with parts pads etc. not just vias. And I can copy-paste objects and move them around just fine as long as they haven't been placed. I agree that it makes no difference whether or not real-time DRC is on. The shift+B crash issue is only in Chrome, Firefox just becomes unresponsive for a few seconds witch is acceptable - at least not surprising, chrome's redirect protocol just at a glance makes it unusable to me, when using a single page application such as Easyeda, because it causes data loss - but again I suspect the chrome issue is on my end, maybe if I turn of hardware acceleration etc. - but my default browser has been Firefox for Years so I haven't looked in to it. I have tried turning of layers but this makes no difference. I have tested this on 3 different PC's (Lenovo laptops) and have this issue on all of them. I should also mention that there were no competing application drawing major resources on any of these laptops while testing. And I have no similar issues with other apps/web-pages. Maybe it has something to do with the drag-protocol itself? ...versus the update rate of the track-pads - except for the fact the the are some coordinates without issues.

@andyfierman I am not seeing any DRC errors on the board - witch is currently in production. Perhaps some differences in Our settings - not the issue though, but thanks for pointing it out =)

The shared version is a clone though....

![DRC setting][1] [1]: /editor/20161025/580f76be096d3.jpg

That's not the PCB Design Manager: that's the basic DRC. Go to the right hand panel and click on the tab that says `Design Manager`. That will open something that looks like this: ![enter image description here][1] Scroll down and `Refresh` the `DRC errors` at the bottom of the list. :) [1]: /editor/20161026/580fda7ab7749.png

Yes, I know this of course =), was just to display the settings - because I am not getting any errors. I think I'm working with some different tolerances than You.

Sorry, I misunderstood. Your screen shot is hard to read but I think your settings are the same as mine: ![enter image description here][1] `Not all vias, for example there is a via at: mouse-X -1109; mouse-Y 1240 (mil) - that i kan move around without issue (also gge554 and gge555)...` Can you give me some XY co-ordinates for objects that you *cannot* move without significant lag? [1]: /editor/20161026/581062c58fc14.png

This is one of the two DRC errors (the other is next to it below and to the left): ![enter image description here][1] Both errors are from the POW_BTN trace to two places around (the piecewise-linear approximation to) the curve of the board outline. [1]: /editor/20161026/5810652b8ee87.png

---------- @Demianaa @Andyfierman let talk the drag VIA make the browser slow and crash at chrome. At present, I have do lots of test. no way to find the problem, this makes us very sadly, if we can't see it, no way to fix.

I have seen - but once only - that when I open the JSON file for this PCB in Chrome, it opens up to just before all the copper areas are filled in and then Chrome just shows the `Aw Snap!` screen.

@Andyfierman gge9621 at X:-650 Y:-2500, but it's most all objects, the couple off coordinates I mentioned earlier were some rare exceptions. **off topic* Regarding the DRC errors You are seeing - I'm not getting that error and I don't think it should be an error; there's 14 mil or so to the outline - but never-mind as mentioned this PCB is already in production. (The DRC *IS* working in general, there must be some differences in our settings).

@Dillon If it helps, even just moving the cursor around in the editor - without dragging anything - uses quite a lot of CPU with my track-pad (not an issue on pages that don't track my cursor). I have a Lenovo Yoga as well so I tried dragging on the touch-screen, the lag still occurred. To me it seems to be related to the update frequency of the onmousemove event.

@Dillon *Firefox 49.0.2 on windows 10

@Dillon Hmm, just checked some pages using drag/drop with my own javascript libraries and they do NOT cause any issues.

Ahhhhhhhhhhhhhhhhhhhhhhhh. Using Firefox 49.0.2 on windows 10, I can see what you mean now. If I select almost any component and drag it quickly with the mouse then there's somnething like 0.5s to 1s lag. **But...** *If I select and drag it even quite slowly but do not stop dragging it then it can be several seconds before the selected object actually moves.* Tried to grab a video but failed. I'll try again later.

Glad it's not me =)

@Demianaa I can confirm your problems. This is the new feature cause this problem(the performance problem), will fix it as next version(a few days) Just check the bellow image, when move the via, we will try to rebuild the net and highlingth it. rebuild the connect relation needs lots of CPU. Why don't find it before. becasue I click a via which is not `GND`, it is `VCC_5`, so rebuild the other net is faster, net verson, move the via don't need to rebuild the ratline. Thanks. ![enter image description here][1] [1]: /editor/20161027/5811ae1f24941.png

@Dillon Ah, OK - so it's dependant on the number of connected objects in the net, so e.g. objects/vias connected to GND and power nets with via stitching/many objects, is bound to give issues. Thanks.

Yes, this is a feature suggested by our user, will help you to find the close pad when move objects. we render it too fast to need lots of time to find the postion. this can be impoved a lot, just need some time.

We just released a new version today, it is should be faster, can you feel? Just make the ratline render to slow when the PCB is a bit litter complex.

Yes, it's much better now.

We always like to hear from our users, even this tool is very hard to develop. We will keep to make EasyEDA better and easy. Thanks for this.

Yeah, You've done a really nice job of making a usable web-based EDA.