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

  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.

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.

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.

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();

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.

The code was reverted and the bug re-introduced.

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.

> ------- 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

 I still don't see that problem, but there is a repaint event missing.  
Different bug...

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

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).  

Furthermore, this bug affects the guide lines (both pre and post initial click) in all zoom modes (X, Y *and* XY).  

  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

  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.

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

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

> 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.

> ------- 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

* 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

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.

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;

Just to confirm, this fixes both bugs for me (both the secondary one I reported, and the original problem Andrew reported).