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

NEW
Unassigned

Status

()

Core
Drag and Drop
--
major
17 years ago
9 years ago

People

(Reporter: beanladen, Unassigned)

Tracking

(Depends on: 1 bug, {perf})

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: have patch; r=? sr=?)

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
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 ?

Comment 1

17 years ago
*** Bug 86139 has been marked as a duplicate of this bug. ***

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 years ago
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
(Reporter)

Comment 5

17 years ago
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
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.

Comment 16

17 years ago
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. ***

Comment 18

17 years ago
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. ***
(Reporter)

Comment 20

17 years ago
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

Updated

16 years ago
Component: BiDi Hebrew & Arabic → XP Apps: Drag and Drop
(Reporter)

Comment 23

16 years ago
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.

Comment 24

16 years ago
*** Bug 164514 has been marked as a duplicate of this bug. ***

Comment 25

16 years ago
qa contact -> pmac
QA Contact: tpreston → pmac
Target Milestone: mozilla0.9.9 → ---

Comment 26

15 years ago
*** Bug 212959 has been marked as a duplicate of this bug. ***

Comment 27

13 years ago
I don't see this amount of traffic in windows XP using remote desktop. Fixed in another bug?

Comment 28

13 years ago
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.

Comment 30

13 years ago
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.
(Reporter)

Comment 32

13 years ago
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.
(Reporter)

Comment 34

13 years ago
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.

Comment 35

13 years ago
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.
(Reporter)

Comment 36

12 years ago
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
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.  :(
Created attachment 246118 [details]
Profile of dragging about for a while inside a blank content area
Attachment #246118 - Attachment is patch: false
Attachment #246118 - Attachment mime type: text/plain → application/zip
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
You need to log in before you can comment on or make changes to this bug.