Am Mittwoch, 12. Juni 2002 14:28 schrieb John Dailey:
> On Wednesday 12 June 2002 04:34 am, Philipp M=FCller wrote:
> > Yes this is the sympthom, but after digging deep into the source and
> > trying to avoid the empty "pixels", I couldn't find a rounding issue
> > here. I rather assume, that the scaling with the worldmatrix adds/remov=
es
> > pixels and the paintBackground function doesn't know about them. I didn=
't
> > find a way to handle them. Even no "hack" :-/
>
> One change that I'll make is to change where the background of the cell is
> cleared.  Instead of clearing each cell individually, we can clear the
> entire block of cells that we are painting at once in KSpreadDocument.=20
> That will certainly simplify much of the painting code (all those
> complicated checks to see if the neighboring cell cleared this cell's
> border) but it will have the side effect of masking the problem of being
> zoomed in.  I suppose that will help for the Beta, at least until we solve
> the problem for real.

AFAIK it's not the clearing, it's the missing/overwritten background. So it=
=20
wouldn't help to clear the foreground, if the background is still missing.

So what I would suppose for a quick hack would be:
1. Pass the zoom value to cellPaint
2. If zoom > 1.5 then paint background always with width+1/height+1.
3. If zoom <> 1.0 repaint right/bottom border too.

Result of the hack would be:
1. Minimal intrusive
2. Performance penulty only when zoom <> 1.0
3. Only one problem: Colored background would overlapp next cell when=20
zoom >1.5, but this would only be visible when there is no border (otherwis=
e=20
the border overpaints the background).
Only 3. would lead to some BR and we can handle this I think.

This would help us already for the Beta and we can work for the correct=20
solution until RC1.

> > > It's not that we're performing any operations on the integers that gi=
ve
> > > a rounding error.
> >
> > Yes we do some operations, which may give rounding errors.
> > 1. width() and height() must always consider where the next cell starts,
> > like I described in my example first.
> > 2, We do at several places
> > for (col =3D first; col<=3D last; col++)
> >    mywidth +=3D column->width()
> > paint(mywidth, y, width,y);
> > For these cases mywidth must be double and we need to use dblWidth().
>
> I don't think this is where the problem is, though, because we've always
> been painting in unzoomed coordinates.  The default cell width/height is
> precisely 60x20.  There is no rounding error because the cell width and
> height are integer values, and these problems show up on default cells th=
at
> have not been resized.

I get more and more the impression, that this is a bug in QT. We have the=20
code:
  QBrush bb =3D backGroundBrush( cellRef.x(), cellRef.y() );

  if( bb.style() !=3D Qt::NoBrush )
  {
    painter.fillRect( corner.x(), corner.y(), width, height, bb );
  }

Why is between fillRect (0,0,60,20,bb) and fillRect(60,20,60,20,bb) an empt=
y=20
line on screen at the lines (119,0,120,40) and (0,39,120,40), when we have=
=20
painter.scale(2.0,2.0)? I rather thinking of a rounding bug in QT now, as=20
this behaviour is really strange. But I didn't test with simple code yet to=
=20
prove this issue.

> Of course, if we start painting in coordinates scaled to the zoom then we
> *will* need the doubles.
>
> > > I'll see what I can dig up on the embedding zoom problem tomorrow.
> > > Hopefully that will be simpler to fix!
> >
> > Fine.
> >
> > Let's try to fix it.
> >
> > Again my hope, that David or Laurent can say something about how
> > KPresenter and KWord is handling zoom, as when we start to reprogrammin=
g,
> > I don't like to change everything and then see that it should have been
> > done
> > differently.
>
> I see David's email....that looks helpful.

Yes, very helpful. I will see what I can do until Sunday.
=46or the Beta2, can you try my above described "hack" and upload it, while=
 I=20
will try to move to the real zoom values and upload it after Beta2 is=20
tagged/released?

Philipp
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel