Open Bug 86138 Opened 23 years ago Updated 4 years ago

Too much network traffic on drag and drop ( use pointer service instead of XQueryTree to figure out the target of DND )

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

All
Linux
defect

Tracking

()

People

(Reporter: beanladen, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: perf, Whiteboard: have patch; r=? sr=?)

Attachments

(6 files)

Hello ! I observed extreme network traffic when using drag and drop over the net (Mozilla started on a remote machine). I measured about 500K traffic (and more) for a simple shift of a mail folder into another one. It seems that this is partly related to the animation (the flyer), but a considerable amount is just doing nothing visible. Compared to the traffic a menu click initiates, this is an extreme waste of bandwidth. Maybe a wrong strategy of background 'save under' causes this ?
*** Bug 86139 has been marked as a duplicate of this bug. ***
Reporter, which build ID on which OS are you using? IMAP or POP3 or news? Are you using Mozilla remote with X? Could you provide steps to reproduce this problem? Please read the bug reporting guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html and consider using Bugzilla Helper http://www.mozilla.org/quality/help/bugzilla-helper.html at to report bugs. Thanks for using Mozilla!
Severity: enhancement → normal
As indicated, this occurs on all builds I ever used (0.8-0.9.1+, Solaris, Linux) remote X (XFree86 4.0.3/Linux 2.4.x-NO backing store or save-under switched on, and Solaris 8 with fvwm 2.3.28) over ISDN. It takes about 2.5-4 minutes in this mode to move a folder into another folder (IMAP or POP is irrelevant for this problem), with an average network traffic of 3.8 kb/second. I've never seen such times for similar operations on old netscape browers. It is most probably a problem with X.
I am almost certain that the problem is the little animation we do on a D&D operation.... Ccing blizzard and pavlov.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Yes, could be, I see a LOT of small flyers piling up along the track before anything is beeing processed.
Yeah, we go batty with XQueryTree(). I might be able to use my new pointer service code in order to do this more efficiently now.
Assignee: blake → blizzard
Summary: Too much network traffic on drag and drop → Too much network traffic on drag and drop ( use pointer service instead of XQueryTree to figure out the target of DND )
Target Milestone: --- → mozilla0.9.3
Attached patch patch (deleted) — Splinter Review
Attached patch cleaner patch (deleted) — Splinter Review
This patch uses the pointer service code to get the inner most window. In addition to being much cleaner and using far less code, it should be a little faster. It's hard to say if it is actually faster since it still uses XQueryPointer() and XTranslateCoordinates(). I basically don't have a choice at this point.
This avoids the overhead of Yet Another XQueryPointer call on each mouse move.
*** Bug 90097 has been marked as a duplicate of this bug. ***
Whiteboard: have patch; r=? sr=?
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Moving out.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Too late for 0.9.6, this needs retargeting.
FWIW, I applied your patch and it's definitely faster than stock 0.9.6, although still not exactly a speed demon. (I use mozilla running on an Intel P3-450, with the X display on a Sparc IPX running Linux over a 10Mbit ethernet connection). I'd say a drag-of-selected-text-and-release is at least twice as fast as it was before, possibly faster. The flyer thingy moving back to the selection on release is now acceptably fast, although performance when dragging it out in the first place is still not wonderful. (This is one of the two bugs that make networked mozilla very irritating; the other is the appallingly slow scrolling of pages with big images in them.) Is there any way to turn off drag-n-drop of selected text? I only ever do this by accident and it's very irritating, especially when it's slow :->
*** Bug 111912 has been marked as a duplicate of this bug. ***
0.9.6 is long gone. -> 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
*** Bug 126380 has been marked as a duplicate of this bug. ***
Maybe I'm just too simple-minded, but couldn't this be solved by exchanging the cursor bitmap at start and stop of dragndrop ? To get the desired effect, no animation is needed at all.
Component: XP Apps: Drag and Drop → BiDi Hebrew & Arabic
This seems to be in the wrong component
Component: BiDi Hebrew & Arabic → XP Apps: Drag and Drop
This is not solved at all. It even seems that the 1.1x series is slower than the ones before. There was also a duplicate a few days ago (may I find it again). I think this needs a much more simple approach, if not dropping the whole animation at all to get things working.
*** Bug 164514 has been marked as a duplicate of this bug. ***
qa contact -> pmac
QA Contact: tpreston → pmac
Target Milestone: mozilla0.9.9 → ---
*** Bug 212959 has been marked as a duplicate of this bug. ***
I don't see this amount of traffic in windows XP using remote desktop. Fixed in another bug?
this is/was a linux bug.
OS: All → Linux
FWIW, I still see this on Linux. Over a local 100Mbit ethernet connection, while dragging, I see: On the client (dual P4 3.6 Ghz cpu): sshd takes up 20% of CPU On the server (P3-733 cpu): ssh takes up 50% of CPU, X takes up 20% more.
the comments, etc in this bug are super old. the patches are for gtk1. if we want a real bug on this issue might want to just mark this one as wontfix and open a new one.
Hey, either way, as long as we fix this. Whenever I use our builds over real remote X I have to be super-careful to not drag unless I want to hang the app for a looong time.
Why creating a new bug ? The problem is still the same, and it got worse. I'm even able to fill up a Gigabit connection on very recent machines (Sun X4200 double Opteron 2.6 GHz) just by calling Seamonkey 1.0 or Mozilla 1.7.12 remotely and trying to use the graphical gimmicks. And it's a very simple task to reproduce it. I don't think this should be wontfix because it's a major usability problem in modern networked environments which is not seen with similar programs which use X. And what about my comment #20 ?
(In reply to comment #32) > I don't think this should be wontfix because it's a major usability problem > in modern networked environments which is not seen with similar programs which > use X. Modern Networked Environments use VNC or Remote Desktop, but that's neither here nor there. X DND is abysmal even on a local desktop; having a drag start is ridiculously bad.
I'm not talking about Windows, but X under Unix. You don't need any additional software which hogs your CPU (see VNC) to run a networked environment with X. Everything you need is already build in.
It is sad to see that in modern computer era one considers the Windows way the only way. Vladimir - on *N*X RDP and VNC are only being used to access the desktop on WIN32. This way (no other possible on WIN) has undesired side effect which is not considered as major drawback by microsoft - taking away unexpectedly the control from another who works on computer in question at the same time. UNIX , which I am sure you know that, is multiuser enviroment, thus introduced X protocol in its very beginning, long long ago, and it is still the only proper way to exploit graphical applications on single machine by multiple users. So - this bug persists and must be fixed. I am still (after 5 years of this bug being submited for the first time) cursing nearly every time I use Mozilla over X since it is so easy to forget about the problem. Just imagine - if it takes so long and so much traffic over LAN, how would you feel working over GPRS or UMTS (G3) ? And I would not say that this bug is problem with X as stated in Comment #3 - it is rather problem with misuse of X in Mozilla.
Problem gets worse. Seamonkey 1.0.5, Firefox 1.5 not usable over network anymore, even simply opening it takes ages. After 20 minutes waiting for a saturated 6 Mb/s line I gave up. Changing severity to major. Something is done plain wrong in Mozilla, I don't know any other X-Application saturating a fast DSL line. This must be fixed !
Severity: normal → major
Depends on: 361354
So I tried profiling this. I'll attach the profiles in a sec. The salient points seem to be bug 361354 and lots of calling into gtk_drag_set_default_icon. I'm not sure we can control this last -- it seems to be deep in GTK guts. :(
Attachment #246118 - Attachment is patch: false
Attachment #246118 - Attachment mime type: text/plain → application/zip
Attached file Same but with --sync (deleted) —
Assignee: blizzard → nobody
QA Contact: pmac
Attachment #246119 - Attachment is patch: false
Attachment #246119 - Attachment mime type: text/plain → application/zip
QA Contact: drag-drop

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: major → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: