[patch] cosmetic fix for KPlotWidget

[Jason Harris]

Ok, I am fine with temporarily shutting off antialiasing when drawing
the plot axes rather than offsetting by 0.5 pixels.  Patch is below.
Ok to commit?

Index: kplotwidget.cpp
===================================================================
--- kplotwidget.cpp     (revision 743854)
+++ kplotwidget.cpp     (working copy)
@@ -548,7 +548,7 @@
     p.begin( this );
     p.setRenderHint( QPainter::Antialiasing, d->useAntialias );
     p.fillRect( rect(), backgroundColor() );
-    p.translate( leftPadding() + 0.5, topPadding() + 0.5 );
+    p.translate( leftPadding(), topPadding() );

     setPixRect();
     p.setClipRect( d->pixRect );
@@ -582,6 +582,10 @@
 }

 void KPlotWidget::drawAxes( QPainter *p ) {
+    //Turn off antialiasing for the axes
+    bool aaOriginal( p->renderHints() & QPainter::Antialiasing );
+    p->setRenderHint( QPainter::Antialiasing, false );
+
     if ( d->showGrid ) {
         p->setPen( gridColor() );

@@ -780,6 +784,9 @@
             p->restore();  //restore translation/rotation state
         }
     }  //End of RightAxis
+
+    //Restore original antialiasing setting
+    p->setRenderHint( QPainter::Antialiasing, aaOriginal );
 }

 int KPlotWidget::leftPadding() const


On 12/1/07, Zack Rusin <zack at kde.org> wrote:
> On Saturday 01 December 2007 01:25:14 pm Jason Harris wrote:
> > The idea behind KPlotWidget is that people don't need to think about
> > the widget's pixel-based coordinate system at all, they can just use
> > their data's natural units and the code takes care of translating it
> > to the screen. So I don't think that shifting the entire coordinate
> > system by (0.5, 0.5) is a problem at all. We've already applied
> > translate( xpadding, ypadding ), where xpadding and ypadding are
> > lengths determined by the code to provide enough room outside the plot
> > axes for showing tick labels and axis labels. I can't imagine a case
> > where anyone would care whether the computer picked PAD or PAD+0.5 for
> > these lengths (where PAD is typically a few tens of pixels).
>
> That's not really what I meant. What I meant is that shift by 0.5 happens to
> shift coordinate system in a way that with the identity matrix makes integer
> based horizontal/vertical lines align with the pixel grid a lot better. This
> doesn't mean that all the primitives (especially ones with many diagonals)
> will align in the same way.
> Plus like I mentioned the shift will in the best case be useless and in the
> worst produce worse results if the users will decide to draw a scaled plot
> (widgets on qgraphicsview will be a good usecase here, because 0.5 can mean
> shift by any arbitrary screen length then [from infinity to zero, altough
> that could be fixed with some clever matrix multiplication])
> But I'm not arguing for anything, especially that I don't have time to
> actually hack on it, so I think you should do whatever makes you comfortable,
> I just wanted to point out some technical aspects of it =)
>
> z
>