Bug 116847 - Problem with X/Y Mouse Zoom mode
Summary: Problem with X/Y Mouse Zoom mode
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: general (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-22 02:21 UTC by Andrew Walker
Modified: 2005-11-24 03:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Walker 2005-11-22 02:21:32 UTC
Version:           HEAD (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
OS:                Linux

PROBLEM:
The dashed line that is drawn when in X/Y Mouse Zoom mode is not always updated correctly as the mouse is moved.

STEPS TO REPRODUCE:
Create some plots in Kst
Click on toolbar icon which allows you to select the graphics mode
Select the X or Y Mouse Zoom menu entry
Identify the plot which was located at the point where the menu entry was selected
In the same plot move the cursor around

RESULTS:
The dashed line drawn while in X/Y Mouse Zoom mode is only updated correctly in the region of the plot that was previously covered by the menu

EXPECTED RESULTS:
The dashed line drawn while in X/Y Mouse Zoom mode is updated correctly in the entire plot
Comment 1 Andrew Walker 2005-11-22 02:46:03 UTC
This is a clean build. I've noticed this for some time now.

-----Original Message-----
From: Barth Netterfield [mailto:netterfield@physics.utoronto.ca]
Sent: Monday, November 21, 2005 5:35 PM
To: 116847@bugs.kde.org; kst@kde.org
Subject: Re: [Kst] [Bug 116847] New: Problem with X/Y Mouse Zoom mode


I don't seem to see this...  can you try a clean rebuild?
_______________________________________________
Kst mailing list
Kst@kde.org
https://mail.kde.org/mailman/listinfo/kst
Comment 2 George Staikos 2005-11-22 03:49:22 UTC
  I don't see any problem either.  It sounds like a video driver bug, if 
anything.  There are bugs in this zoom mode but I don't know of any that meet 
this description.
Comment 3 Andrew Walker 2005-11-22 19:39:30 UTC
The problem was caused by the following change in 
void KstTopLevelView::paint(KstPaintType type, QPainter& p, const QRegion& bounds)

if (bounds.isNull()) {     
    p.setClipRegion(clipRegion());
} else {
    p.setClipRegion(bounds);
}

If a menu covers up some part of a plot when in X/Y Zoom mode then the clip region is set to the region defined by that menu and only that region is updated. I don't see anywhere that this clip region is then cancelled, so further updates of the X/Y Zoom mode line are made only within the clip region - which is exactly what I am seeing. Also, if I revert the portion of code above then everything behaves as expected.

Unless I hear otherwise I'll add a call to p.setClipping(false) in a sutiable loaction to fix this problem.
Comment 4 Andrew Walker 2005-11-22 22:09:40 UTC
Looking at this further the problem seems to be caused by setting _lastClipRegion associated with a plot to just the area under the menu. The only solution that I can see (barring a complete of the cached clip regions) is to revert the change that was made in void KstTopLevelView::paint(KstPaintType type, QPainter& p, const QRegion& bounds) in order to optimize painting.

Unless I hear otherwise I'll revert the change.
Comment 5 Andrew Walker 2005-11-22 22:35:08 UTC
SVN commit 482410 by arwalker:

BUG:116847 Ensure that X/Y Zoom mode line is updated correctly

 M  +4 -5      ksttoplevelview.cpp  


--- trunk/extragear/graphics/kst/kst/ksttoplevelview.cpp #482409:482410
@@ -149,11 +149,10 @@
   QTime t;
   t.start();
 #endif
-  if (bounds.isNull()) {
-    p.setClipRegion(clipRegion());
-  } else {
-    p.setClipRegion(bounds);
-  }
+  // if attempts are made to optimize here please
+  //  read and test for bug report #116847 before 
+  //  checking in any code changes...
+  p.setClipRegion(clipRegion());
   KstViewObject::paint(type, p, bounds);
 #ifdef BENCHMARK
   int x = t.elapsed();
Comment 6 Andrew Walker 2005-11-22 22:53:53 UTC
The problem is that the clipping wasn't being forgotten, but getting cached.
The menu has to overlap with a plot region, and when you select the
Y Mouse Zoom mode the cursor has to have a plot located within it.
When the menu is closed your mouse has to remain with the same plot.
Sometimes it has to be done twice, and you'll see the problem only the
second time.
Comment 7 Andrew Walker 2005-11-23 19:13:06 UTC
The code was reverted and the bug re-introduced.
Comment 8 Andrew Walker 2005-11-23 20:02:56 UTC
A simpler way to reproduce the problem is as follows:

Using static data create a single plot in Kst
Make both Kst and the single window full size
Select the Y Mouse Zoom mode
Right click in the middle of the window to bring up the context menu
Dismiss the menu by left-clicking outside of it
Move the cursor around in the window and notice that the guideline
is only updated in the region previously occupied by the menu

I would be interested to know whether anyone can reproduce this
with the code as it presently stands.
Comment 9 Matthew Truch 2005-11-23 20:07:36 UTC
> ------- Additional Comments From arwalker sumusltd com  2005-11-23 20:02 -------
> A simpler way to reproduce the problem is as follows:
> 
> Using static data create a single plot in Kst
> Make both Kst and the single window full size
> Select the Y Mouse Zoom mode
> Right click in the middle of the window to bring up the context menu
> Dismiss the menu by left-clicking outside of it
> Move the cursor around in the window and notice that the guideline
> is only updated in the region previously occupied by the menu
> 
> I would be interested to know whether anyone can reproduce this
> with the code as it presently stands.


I have just tried to reproduce this (with svn trunk), and confirm
exactly what you (Andrew) are seeing.  This is FC-4 on i386 fully
updated and running in a fully kde (no gnome) environment:

[matt@cherry ~]$ kst --version
Qt: 3.3.4
KDE: 3.4.2-0.fc4.1 Red Hat
Kst: 1.2.0_svn_482480
Comment 10 George Staikos 2005-11-23 20:17:44 UTC
 I still don't see that problem, but there is a repaint event missing.  
Different bug...
Comment 11 Ted Kisner 2005-11-23 20:18:40 UTC
On Wednesday 23 November 2005 11:02, Andrew Walker wrote:
| Using static data create a single plot in Kst
| Make both Kst and the single window full size
| Select the Y Mouse Zoom mode
| Right click in the middle of the window to bring up the context menu
| Dismiss the menu by left-clicking outside of it
| Move the cursor around in the window and notice that the guideline
| is only updated in the region previously occupied by the menu
|
| I would be interested to know whether anyone can reproduce this
| with the code as it presently stands.

I don't see anything unusual on a Kubuntu-AMD64 system (KDE 3.4.3, Qt 3.3.4, 
Xorg 6.8.2).  I'm doing an update and recompile now to see if anything has 
changed...

-Ted
Comment 12 Matthew Truch 2005-11-23 20:39:13 UTC
I don't know if this is related specifically to this bug: I also see problems when something unrelated to kst 'animates' over the kst plot.  If this happens, the guide line stops getting updated at all (is frozen where it was when the 'animation' happened).  This happens to me specifically when the panel autohides itself after covering up the bottom portion of the kst window (I have to turn on the ever annoying auto-hide as my screen is only 1024x768 so every little bit of real estate is precious).  
Comment 13 Matthew Truch 2005-11-23 20:49:05 UTC
Furthermore, this bug affects the guide lines (both pre and post initial click) in all zoom modes (X, Y *and* XY).  
Comment 14 George Staikos 2005-11-23 21:13:58 UTC
  Could everyone with problems please post:
1) video chipset, exactly and specifically
2) linux distribution and version - including any patches to X11
3) exact X server RPM/package and version number
4) exact video driver in use
Comment 15 George Staikos 2005-11-23 21:37:55 UTC
  I managed to trace down my problem but I still don't think it's related to 
what Andrew sees.  It -might- be related to what Matt sees.  I hope to have a 
fix shortly.  The clip region is correct and the paint event arrives, but the 
focus plot doesn't paint for some reason.
Comment 16 George Staikos 2005-11-23 21:49:56 UTC
Continuing diagnosis, here is what happens:
Click on P0 to close the menu causes a click event on the plot
Click event triggers zoom paused
Then the paint event arrives
   -> zoom paused causes paint in the plot to bail out
Release event undoes zoom paused
Next repaint will correct things
Comment 17 Andrew Walker 2005-11-23 22:32:46 UTC
An even simpler scenario:

Press and hold right mouse button to bring up context menu
Move mouse so that the cursor is away from the menu slightly
Release right mouse button to dismiss menu

Same problem but _zoomPaused is never true
Comment 18 George Staikos 2005-11-23 22:36:29 UTC
> Press and hold right mouse button to bring up context menu
> Move mouse so that the cursor is away from the menu slightly
> Release right mouse button to dismiss menu
>
> Same problem but _zoomPaused is never true


  Can't reproduce that.  I need the answer to all the questions and traces we 
asked for before I investigate that any further.
Comment 19 Matthew Truch 2005-11-23 22:43:32 UTC
> ------- Additional Comments From staikos kde org  2005-11-23 21:13 -------
>   Could everyone with problems please post:
> 1) video chipset, exactly and specifically
> 2) linux distribution and version - including any patches to X11
> 3) exact X server RPM/package and version number
> 4) exact video driver in use


1) ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)
2) Fedora Core 4
3) xorg-x11-6.8.2-37.FC4.49.2
4) Module ati: vendor="X.Org Foundation" compiled for 6.8.2, module version = 6.5.6

Cut and pasted from the following commands, respectivly: 
lspci, cat /etc/fedora-release, rpm -q xorg-x11, cat /var/log/Xorg.0.log
Comment 20 Andrew Walker 2005-11-23 22:52:17 UTC
* 01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200] (rev a1)
* Fedora Core release 3 (Heidelberg)
* xorg-x11-6.8.1-12
* Module nv: vendor="X.Org Foundation"
        compiled for 6.8.1, module version = 1.0.1
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 0.7
Comment 21 George Staikos 2005-11-23 23:38:43 UTC
On Wednesday 23 November 2005 16:43, Matthew Truch wrote:
> 1) ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)
> 2) Fedora Core 4
> 3) xorg-x11-6.8.2-37.FC4.49.2
> 4) Module ati: vendor="X.Org Foundation" compiled for 6.8.2, module version
> = 6.5.6


  I reproduced Matt's problem now, but I still can't reproduce Andrew's.  I'll 
put traces in to see why the paint events are incorrect for the animation 
case.  I'm using a Radeon mobility with xorg 6.8.1 on suse.  Not too much in 
common here.
Comment 22 George Staikos 2005-11-24 01:24:33 UTC
SVN commit 482739 by staikos:

Fix Matt's bug and basically put Andrew's patch back with the bounds clipping
moved into kstviewobject instead.  It's a bit slower, but much faster than
painting regions we don't need to paint.  There are still issues with the
guidelines, but they were always there and not related to any of these bugs.
Still can't reproduce what Andrew sees though, so I don't know for sure that
it fixes it, and even then, why.
BUG: 116847


 M  +1 -1      kst2dplot.cpp  
 M  +1 -5      ksttoplevelview.cpp  
 M  +5 -6      kstviewobject.cpp  
 M  +2 -2      kstviewwidget.cpp  


--- trunk/extragear/graphics/kst/kst/kst2dplot.cpp #482738:482739
@@ -2236,7 +2236,7 @@
     _oldAlignment = alignment;
     _oldSize = sizeNew;
 
-    kstdDebug() << " -> paint plot " << tagName() << " with clipRegion: " << p.clipRegion() << endl;
+    //kstdDebug() << " -> paint plot " << tagName() << " with clipRegion: " << p.clipRegion() << endl;
     _buffer.paintInto(p, geometry());
     drawCursorPos(p);
     updateTieBox(p);
--- trunk/extragear/graphics/kst/kst/ksttoplevelview.cpp #482738:482739
@@ -149,11 +149,7 @@
   QTime t;
   t.start();
 #endif
-  if (bounds.isNull()) {
-    p.setClipRegion(clipRegion());
-  } else {
-    p.setClipRegion(bounds);
-  }
+  p.setClipRegion(clipRegion());
   KstViewObject::paint(type, p, bounds);
 #ifdef BENCHMARK
   int x = t.elapsed();
--- trunk/extragear/graphics/kst/kst/kstviewobject.cpp #482738:482739
@@ -324,7 +324,11 @@
         t.start();
 #endif
         (*i)->_lastClipRegion = clipRegion;
-        p.setClipRegion(clipRegion);
+        if (nullBounds) {
+          p.setClipRegion(clipRegion);
+        } else {
+          p.setClipRegion(clipRegion.intersect(bounds));
+        }
         (*i)->paint(type, p, bounds);
         clipRegion -= (*i)->clipRegion();
 #ifdef BENCHMARK
@@ -340,11 +344,6 @@
 
   p.setClipRegion(oldRegion);
 
-  if (_focus) {
-    //kstdDebug() << "Object " << tagName() << " has focus" << endl;
-    //drawFocusRect(p);
-  }
-
   if (isSelected()) {
     //kstdDebug() << "Object " << tagName() << " is selected" << endl;
     drawSelectRect(p);
--- trunk/extragear/graphics/kst/kst/kstviewwidget.cpp #482738:482739
@@ -354,10 +354,10 @@
   if (e) {  // Resize/expose/etc triggered by X11
     QRegion r = e->region();
     if (r.isEmpty()) {
-      kstdDebug() << "Paint event with NO region" << endl;
+      //kstdDebug() << "Paint event with NO region" << endl;
       _view->paint(_nextUpdate);
     } else {
-      kstdDebug() << "Paint event with region " << e->region() << endl;
+      //kstdDebug() << "Paint event with region " << e->region() << endl;
       _view->paint(_nextUpdate, e->region());
     }
     _nextUpdate = P_PAINT;
Comment 23 Matthew Truch 2005-11-24 03:45:55 UTC
Just to confirm, this fixes both bugs for me (both the secondary one I reported, and the original problem Andrew reported).