[patch] cosmetic fix for KPlotWidget

[Jason Harris]

Hello,

On 11/30/07, Zack Rusin <zack at kde.org> wrote:
> Except that there is no bug in Qt.
>
I agree with you that there is no bug in Qt, and that the fix belongs
in KPlotWidget (if anywhere).

> Personally I don't think the patch is correct. Shifting the whole coordinate
> system just means that other parts of the rendered primitives now fall out of
> pixel bounderies. So you're effectively exchanging certain parts of the
> anti-aliased lines that happen to be anti-aliased in a way you don't like for
> others which will be anti-aliased in a way you don't like. But then again I
> haven't looked at the code for KPlotWidget and don't have time for it so I
> don't think my voice counts.
>
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).

Anyway, like I said, if someone does want fuzzy axes, they are free to
apply different translate() values in their subclass...

> The only way to get pixel snapping working is to pixel snap coordinates of the
> primitives themselves not to shift the whole world matrix. Disabling
> antialiasing for horizontal/vertical lines and drawing them in a seperate
> pass would also work.
>
If people think this is preferable, even given the above argument,
then I can certainly do it this way too.  I don't see a practical
difference, so whatever makes people happy is fine.

> One could probably ask trolls to pixel-snap horizontal/vertical lines in
> qpainter if it happens to be drawing with the identity matrix. But again,
> personally I think it's up to developers to decide how they want their
> rendering to look like, Qt's job is to do exactly what the developers tell it
> to do and not try to magically figure out for developers what they want.
>
Agreed, there's no bug to be fixed in Qt.