[Kst] extragear/graphics/kst/kst

[George Staikos]

On Tuesday 22 November 2005 18:56, you wrote:
> George, I believe that in KstViewObject::paint(KstPaintType type, QPainter&
> p, const QRegion& bounds) the QRect _lastClipRegion for the plot which was
> partially obscured by the layout menu is getting to set the region that
> needs to be updated - which is the area previously covered by the menu.
>
> When I then move the mouse within the same plot
> Kst2DPlot::mouseMoveEvent(QWidget *view, QMouseEvent *e) then sets the
> clip region to this same _lastClipRegion (i.e. the region previously
> covered by the menu) and updates the XY guideline, but (as is to be
> expected) it gets updated only within the clip region.
>
> The end result is the problem that is described in the 116847 bug report.
>
> Your recent changes seem to have reintroduced this problem. While I'm
> perfectly willing to accept that there may be some bug in the X11 driver I
> am using (I'm sure such bugs are common) I'm concerned that we not dismiss
> this bug so quickly just because you are unable to repdroduce it. As a
> starting point could you indicate where my argument falls apart.

  Which argument?
- There are X11 bugs so we should work around them:
	Yes, we should, but not by making our paints 2-4 times slower in the average 
case.

- My patch still breaks it:
	Possibly, but it does restore the clip region which you claim was the 
problem.  In the worst case this could make one paint invalid and it will be 
fixed after that.  If it's not fixed, then perhaps the bug lies inside 
Kst2DPlot.

  A bug in a video driver or X11, or even a bug in Kst2DPlot should not be 
fixed by making all painting slower, period.  I spent a lot of time trying to 
make painting fast again after it was completely broken this summer and it 
needs to stay that way.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/