[Kst] extragear/graphics/kst/kst

[Andrew Walker]

My argument would be the first two paragraphs.

Why assume its an X11 bug when we have no evidence?

How does your patch restore the value of _lastClipRegion?

Given a choice between slower correct painting and faster
incorrect painting then slower painting it is.

-----Original Message-----
From: George Staikos [mailto:staikos at kde.org]
Sent: Tuesday, November 22, 2005 4:33 PM
To: kst at kde.org
Subject: Re: [Kst] extragear/graphics/kst/kst


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/
_______________________________________________
Kst mailing list
Kst at kde.org
https://mail.kde.org/mailman/listinfo/kst