[haiku-appserver] Re: partly paiting

  • From: Adi Oanca <adioanca@xxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 27 Oct 2005 23:14:45 +0300

Hi again,

Stephan Aßmus wrote:

It's clearer now?

Not really. Do you just mean that:

view->ScrollTo(-5, -5);

will dump two different bounds? (the second is shifted, as is the
origin of the local coordinate system)

I'm not sure about that. The Bounds() rectangle is like the currently visible portion of the views contents. When you scroll a view, another portion of the contents are displayed. In another words, the Bounds() rectangle changes. However, the coordinate system origin is something different, I think:

suppose Origin() = B_ORIGIN, then

StrokeLine(BPoint(5, 5), BPoint(10, 5));

will draw a line at a certain position in the view.

SetOrigin(5, 5);
StrokeLine(BPoint(0, 0), BPoint(5, 0));

will draw the very same line (on screen), everything else being equal.

Yup, exactly.
Another thing, that I forgot to put in the previous mail:
Changing to parent coordinates does not consider the local origin, BUT, drawing primitives does. Strange how they could slip this.

I don't really know what happens to Bounds() after calling SetOrigin() like that. But I do know that Origin() will not be affected by simply scrolling the view (shifting the visible portion of the contents). I would find it logical if Bounds() returned something different after SetOrigin(), but without actual scrolling of course. But the Be implementation *could* be buggy or inconsequent or whatever you want to call it. We need to test that.

I don't know what Be did, but I have a strong feeling that the inconsistency with the local origin and the bounds rectangle are somehow related.
In R5, changing the local origin, _does not_ change the bounds rectangle, thus no (auto)scrolling takes place.
If we want to fix this "local origin" problem, we need to change the bounds rectangle so that we will not get and automated scroll. I think this is the right way to go.



Other related posts: