[haiku-appserver] Re: partly paiting

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 27 Oct 2005 16:13:24 +0300

Ola,

Axel Dörfler wrote:
for this; I can only recommend this one to everybody :-)

OK then, I'll use qemu.

        You are going to take care of multiple monitor issue along with
mapping VirtualScreens to Workspaces?
        RootLayer locking through MultiLocker, maybe?
        What else?

Also the RootLayer/Desktop/ServerWindow/Input Handling separation. My original proposal was:
http://www.freelists.org/archives/haiku-appserver/06-2005/msg00085.html


In the ongoing discussion after that, it was vastly improved, though :-
)

:-) Yeah. I hope we understood each other, as I remember the talk was not that... clear, if I might say so. :-)

I found a problem in the way we scroll views. ATM, we scroll views
by modifying a view's origin. I think this is not correct. We should change
the bounds rectangle only, and not touch the view's origin. (Also, modifying
a view origin, will modify a view's bounds rectangle accordingly, otherwise,
there would an "autoscroll" action why I don't think we want.)

I don't think you're right here (at least if I understand you correctly) - why should the view's bounds are changed when you scroll the view? That can't really work.
In case you are confused by the BScrollView class: that's only a helper, you can scroll a single view alone without any other views - and you certainly don't want to move the view around in that case, just its contents.

Wait a second. I think there is a big communication issue here. Or, misunderstanding of bounds/scrolling/local_coordinates.

        I'll explain what I understand.

        You have the frame rectangle which I see as the size of a view 
(described in parent coords).
        You have a local coordinate system with a local origin.
        You have a "view(window) area; (maybe the term viewport is better?)" 
which is exactly the size
of the view but it's in local coordinates and by default has its left top 
corner at the origin of the
local coordinate system.
        Scrolling a view means: modify the bounds rectangle(NOT its size) so that it 
"points" to another
area of the local coordinate system. It's merely an OffsetTo(x,y). Local coord 
system's origin is NOT
modified.
        Modifying the local coordinate system's origin, is a completely 
different thing than the bounds
rectangle of a view. However they _must_ be related, because you don't see a 
view scrolling automatically
to a new position because its bounds rectangle did not change. That's why I 
think when setting a local
origin the bounds rectangle must be modified(relocated) so that it points to 
the same area as it did
before the origin was set.

        It's clearer now?

Sure, that would be nice.
        OK then.
        Also, I will try to make the changes I spoke about 2 weeks ago:
    MarkDirty(reg);, MarkDirty(reg); MarkDirty(reg); ...
    TriggerRedraw(rebuild=true); (false - just redraw. no visible reg
                                                        recalculation)

Okay, I'll first have a look at this font crashing bug.

Do we have such a bug? :-)



bye,
Adi.

Other related posts: