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)
Tracking
()
NEW
People
(Reporter: beanladen, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf, Whiteboard: have patch; r=? sr=?)
Attachments
(6 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/zip
|
Details | |
(deleted),
application/zip
|
Details |
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 2•23 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
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.
Comment 4•23 years ago
|
||
I am almost certain that the problem is the little animation we do on a D&D
operation.... Ccing blizzard and pavlov.
Yes, could be, I see a LOT of small flyers piling
up along the track before anything is beeing processed.
Comment 6•23 years ago
|
||
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 )
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.3
Comment 7•23 years ago
|
||
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
This avoids the overhead of Yet Another XQueryPointer call on each mouse move.
Comment 12•23 years ago
|
||
*** Bug 90097 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
Updated•23 years ago
|
Whiteboard: have patch; r=? sr=?
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 15•23 years ago
|
||
Too late for 0.9.6, this needs retargeting.
Comment 16•23 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 :->
Comment 17•23 years ago
|
||
*** Bug 111912 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 19•23 years ago
|
||
*** Bug 126380 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 20•23 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
Comment 21•23 years ago
|
||
huh?
Comment 22•23 years ago
|
||
This seems to be in the wrong component
Reporter | ||
Comment 23•22 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•22 years ago
|
||
*** Bug 164514 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → ---
Comment 26•21 years ago
|
||
*** Bug 212959 has been marked as a duplicate of this bug. ***
Comment 27•19 years ago
|
||
I don't see this amount of traffic in windows XP using remote desktop. Fixed in another bug?
Comment 29•19 years ago
|
||
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•19 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.
Comment 31•19 years ago
|
||
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•19 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•19 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•19 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•18 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
Comment 37•18 years ago
|
||
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. :(
Comment 38•18 years ago
|
||
Updated•18 years ago
|
Attachment #246118 -
Attachment is patch: false
Attachment #246118 -
Attachment mime type: text/plain → application/zip
Comment 39•18 years ago
|
||
Updated•18 years ago
|
Assignee: blizzard → nobody
QA Contact: pmac
Updated•18 years ago
|
Attachment #246119 -
Attachment is patch: false
Attachment #246119 -
Attachment mime type: text/plain → application/zip
Updated•15 years ago
|
QA Contact: drag-drop
Comment 40•4 years ago
|
||
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.
Description
•