|
 Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Stephan on Jun-01-2015 22:27 |
|
Hello there,
we do experience some performance issues with the zoom selection box and mouse tracking.
The issues are reproducable with zoomscrolltrack, which is bundled with your Chart Director download file. So no need to send you some example code from our source.
Our environment:
- Linux 64 Bit (CentOS 6.6)
- Qt 4.7.4, we compile it from source, results in 32 bit binaries
- Chart Director 5.1.1, 32 bit version
- We are working with C++, here too, result are 32 bit binaries of course
Setup 1:
zoomscrolltrack running on local machine. Everything works fine and smooth, no performance issues.
Setup 2:
zoomscrolltrack running on a remote machine, connected to it with an ssh, secure shell, session with -X option to get X window data transferred to us. We do get only few, even no mouse tracking information passed at all. So no information shown when hovering over a given signal. And when zooming, the zoom selection box is not drawn smoothly, but stuttering, sometimes it is almost impossible to make an accurate selection. And last thing we note, the CPU usage of the sshd daemon process is going up to 70, even 90 percent. Even though I move the mouse pointer very slowly over the zoomscrolltrack window.
Do you have an idea what reason this could have ?
Thanks for your help.
Stephan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Peter Kwan on Jun-01-2015 23:42 |
|
Hi Stephan,
In ChartDirector, the track cursor, including the zoom selection box, works using
something like an "animation". When you move the mouse, ChartDirector immediately
generates new frames in the animation to show the track cursor moving and labels get
updated. In other words, anything that moves on the chart does so by completely
updating the entire chart, similar to playing an animation or flash movie, where each
frame completely replaces the previous frame.
We frequency test our systems using Windows remote desktops over LAN, and it works
fine. (We run our Linux machine as virtual machine on a Windows machine. So the Linux
desktop appears is displayed on a virtual machine window in the Windows machine. Then
we remotely access that Windows machine using Windows remote desktop.)
I am not sure internally how the "X remote" works, and how fast is the SSH system and
its overhead. I suspect the "X remote" is trying to send the entire frame to the display
machine. As there can be many frames per second when the mouse moves, if it is not on
a LAN connection, the bandwidth may not be fast enough. Another possibility is the SSH
is too CPU intensive (the encryption can be very CPU intensive) and the CPU is not fast
enough to encrypt the frames in realtime. (We sometimes use SSH for file transfer, and in
our case, it indeed is much slower than non-encrypted transfer.) If the "X remote" tries
to compress the frame first before sending it, it can reduce bandwidth, but compression
is CPU intensive too, and the CPU may not be fast enough for realtime compression of
frames.
May be you can try to use a non-encryption connection (not SSH) over LAN to see it
there is any difference. This can confirm if it is due to the bandwidth or overhead of the
SSH.
Regards
Peter Kwan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Stephan on Jun-04-2015 13:44 |
|
Hello Peter,
thank you for the explanation of how these events are handled. But it do not understand why simply hovering with the mouse over the chart does also need that much network bandwidth.
We are using the HTML image map to display a legend box for the current mouse pointer position. But even if I have an empty chart, only axis are drawn, no data yet, I have my ssh server process occupying 70% up to 90% of the CPU. Do you also redraw the image in this case ?
Thanks, Stephan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Stephan on Jun-04-2015 23:27 |
|
Hello Peter,
sorry writing again, I guess I might as well answer my previous question myself, it is QChartViewer::commitMouseMove(QMouseEvent*) that is calling commitUpdateChart() all the time right ?
Kind regards, Stephan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Peter Kwan on Jun-04-2015 23:43 |
|
Hi Stephan,
The mouse pointer is not part of the chart and is not related to the chart. For example,
when you write your own application, you do not need to draw or or worry about the mouse
pointer. The mouse pointer is a separate entity provided by the GUI framework (the X-
Window system for your case).
When you move the mouse pointer, the X system probably only sends the mouse pointer
position to the X terminal, and not other parts of the screen (since the mouse pointer is not
related to any application), so it takes a lot less bandwidth.
Similarly, if the chart is changed (eg. by calling "updateDisplay"), the X system probably
only sends the chart to the X terminal, but not the other part of the screen, but the chart
itself is much larger than the mouse, so it may take more bandwidth.
For your case, are you calling the "updateDisplay" in the mouse move event handler? If this
is the case, the chart will be updated and it can occupy bandwidth.
I am not too sure what is your code structure to "using the HTML image map to display a
legend box for the current mouse pointer position". HTML image map (generated with
getHTMLImageMap) is usually used to define hot spots for tooltips. ChartDirector will not
update the chart when processing the image map (unless your own code update the chart).
The tooltip box is not rendered by ChartDirector, but is by Qt. It is just a regularly Qt tooltip
box, and is the same tooltip box that appears in other Qt controls.
Regards
Peter Kwan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Peter Kwan on Jun-06-2015 05:34 |
|
Hi Stephan
From my understanding of the code, commitMouseMove will first set a flag
"m_delayUpdateChart = NEED_DELAY;". Then it will fire the mouseMouseChart,
mouseMovePlotArea and other mouse move events. Finally, it will call "commitUpdateChart".
The commitUpdateChart will not update the chart if m_delayUpdateChart is set to
NEED_DELAY, so no update should occur. However, if in these mouse move events, some
code changes the chart and call "updateDisplay", the flag will change and the
commitUpdateChart will update the chart. This means the chart will get updated during
mouse move only if the chart has been changed during mouse move.
Regards
Peter Kwan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Stephan on Jun-11-2015 21:26 |
|
Hello Peter,
thank you for your replies, I will have a look at my code for superfluous update calls.
I do however not understand why zoomscrolltrack, which is delivered with the library, does also have the very same issues. Does zoomscrolltrack do too much updates calls too some where ?
Kind regards, Stephan |
| Re: Zoom and mouse tracking very slow on XWindow server over ssh connection |
| Posted by Peter Kwan on Jun-12-2015 01:32 |
|
Hi Stephan,
Do you mean that the "zoomscrolltrack" works normally on X Remote? If this is the case,
may be the X Remote can handle the screen update after all. The issue may then be due to
excessive screen update cause by other factors.
The "zoomscrolltrack" will update the screen as fast as the mouse event occur. For there is
10 mouse move events within a second, it will update the screen 10 times in a second.
There is also built-in rate control that limits the update to at most 50 times per second.
Note that ChartDirector will not automatically update the display. It will only update the
display if either QChartViewer::setChart is called, or QChartViewer::updateDisplay is called.
In "zoomscrolltrack", the updateDisplay is called in the mouse move event handler, so that
chart is updated as fast as the mouse move events.
For displaying tooltips, ChartDirector will create the tooltip text and asks Qt to the display it
(using QToolTip::showText). ChartDirector does not know how the tooltip will be displayed.
Qt will automatically choose the tooltip position, font, text size, etc., to display the tooltip.
It is not sure how the display will be updated in this case.
For your case, does your code calls "updateDisplay" or "setChart" very frequently? You may
consider to display tooltips to see if this is causing the issue. If the issue still occurs, is it
possible there is some other things in your code that is triggering the update?
Regards
Peter Kwan |
|
Forum Home
Search
Message List
Post Message