scrolling seems to work nicely, dirty regions are tracked fine and shifted along with the scrolling if necessary

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15277 a95241bf-73f2-0310-859d-f6bbb57e9c96

showing and hiding windows and views works now, views are not so heavily tested, but any problems should be easy to fix. the recursive IsHidden() is now avoided, there is only one recursion now, which is when the hidden status changes. in the simulation, double clicking a window will temporarily hide it and show it asynchronously from the window thread. looks like the locking model works out fine.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15272 a95241bf-73f2-0310-859d-f6bbb57e9c96

figured out and solved several problems:
* views are now correctly clipped when they are
(partly) hidden under their parent(s)
* removed fIsTopView, the top view in a window
simply has no parent
* introduced WindowLayer::CopyContents() which
blits part of the contents to another location,
while moving that part in the dirty regions. Since
this is currently used from the Desktop thread,
messing with the update session dirty regions
requires now to lock the clipping
* that feature is now used for blitting a view to its
new location in ViewLayer::MoveBy(), which
works for right and/or bottom aligned views just fine
* I left the global dirty region in Desktop for now,
moving it into each WindowLayer gave quite a slowdown
and caused all kinds of other problems.
* a view is now cleared to the background color right
before the first drawing command from the client
is executed for that view, this reduces flickering
a lot because the content is drawn much more shortly
after the background is cleared.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15201 a95241bf-73f2-0310-859d-f6bbb57e9c96

Played a bit :-)
* Introduced WindowLayer::Hide/Show/IsHidden()
* Made ViewLayer::IsHidden() more robust.
* Same with ::TopLayer()
* modified a little ViewLayer::MoveBy() - prepared it to work with
hidden/shown code that will come soon; only calculate dirty regions if a
ViewLayer has a parent, otherwise the move action is pointless.
* Did the same thing with ::MoveBy() except for the parent stuff - no need
for a parent on resizing.




git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15193 a95241bf-73f2-0310-859d-f6bbb57e9c96

ViewLayers screen clipping is clipped to the parent bounds, but that is only a partial fix and should be done more elegantly. When moving a window, the part that we could blit is certainly not dirty, the pending dirty region that we drag along is clipped to the new visible region of the moved window

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15170 a95241bf-73f2-0310-859d-f6bbb57e9c96

still buggy but less buggy than before, more caching and less overhead

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15160 a95241bf-73f2-0310-859d-f6bbb57e9c96

* adds drawing commands from clients
* adds concept of a current and a pending update session
* marks dirty views being resized or moved

Some aspects of the design are buggy, others are slow, but I'm
approaching a good overview of what's needed and what problems
lurk in the details. In the end I hope to make things work fast
and correctly at all times. Adi or anybody else, feel free to
join the efforts.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15158 a95241bf-73f2-0310-859d-f6bbb57e9c96

* a bit more sophisticated
* now with actual view layers inside the windows
* implemented the resize modes (from Adis code)
* windows have resize handles and more correctly
clip the views inside
* bringing windows to front or sending them behind all others
* one active window, the others are inactive
* with and without focus follows mouse mode

* bugs:
- the region marked dirty when views are
resized is not correct yet

* todo:
- move the dirty region from being managed by the
desktop to being managed in each window (and being
local too)
- scrolling
- hiding/showing of windows and views

I plan to extend this to fully simulate asynchronous
drawing from clients, to see any problems before
using this in the real server one day.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15132 a95241bf-73f2-0310-859d-f6bbb57e9c96

Adi and I have had long talks about better approaches to clipping and we are convinced that a different design can significantly speed up the clipping processing in the root layer thread. This is a first prototype implementing the new ideas. Lots of features are missing yet, but Adi asked me to commit it now, so that we can both continue to work on it. The purpose of the new design is to significantly reduce the computations during an atomic clipping update, and also to scale much better with many more open windows.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15101 a95241bf-73f2-0310-859d-f6bbb57e9c96

scrolling seems to work nicely, dirty regions are tracked fine and shifted along with the scrolling if necessary

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15277 a95241bf-73f2-0310-859d-f6bbb57e9c96

showing and hiding windows and views works now, views are not so heavily tested, but any problems should be easy to fix. the recursive IsHidden() is now avoided, there is only one recursion now, which is when the hidden status changes. in the simulation, double clicking a window will temporarily hide it and show it asynchronously from the window thread. looks like the locking model works out fine.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15272 a95241bf-73f2-0310-859d-f6bbb57e9c96

figured out and solved several problems:
* views are now correctly clipped when they are
(partly) hidden under their parent(s)
* removed fIsTopView, the top view in a window
simply has no parent
* introduced WindowLayer::CopyContents() which
blits part of the contents to another location,
while moving that part in the dirty regions. Since
this is currently used from the Desktop thread,
messing with the update session dirty regions
requires now to lock the clipping
* that feature is now used for blitting a view to its
new location in ViewLayer::MoveBy(), which
works for right and/or bottom aligned views just fine
* I left the global dirty region in Desktop for now,
moving it into each WindowLayer gave quite a slowdown
and caused all kinds of other problems.
* a view is now cleared to the background color right
before the first drawing command from the client
is executed for that view, this reduces flickering
a lot because the content is drawn much more shortly
after the background is cleared.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15201 a95241bf-73f2-0310-859d-f6bbb57e9c96

Played a bit :-)
* Introduced WindowLayer::Hide/Show/IsHidden()
* Made ViewLayer::IsHidden() more robust.
* Same with ::TopLayer()
* modified a little ViewLayer::MoveBy() - prepared it to work with
hidden/shown code that will come soon; only calculate dirty regions if a
ViewLayer has a parent, otherwise the move action is pointless.
* Did the same thing with ::MoveBy() except for the parent stuff - no need
for a parent on resizing.




git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15193 a95241bf-73f2-0310-859d-f6bbb57e9c96

ViewLayers screen clipping is clipped to the parent bounds, but that is only a partial fix and should be done more elegantly. When moving a window, the part that we could blit is certainly not dirty, the pending dirty region that we drag along is clipped to the new visible region of the moved window

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15170 a95241bf-73f2-0310-859d-f6bbb57e9c96

still buggy but less buggy than before, more caching and less overhead

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15160 a95241bf-73f2-0310-859d-f6bbb57e9c96

* adds drawing commands from clients
* adds concept of a current and a pending update session
* marks dirty views being resized or moved

Some aspects of the design are buggy, others are slow, but I'm
approaching a good overview of what's needed and what problems
lurk in the details. In the end I hope to make things work fast
and correctly at all times. Adi or anybody else, feel free to
join the efforts.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15158 a95241bf-73f2-0310-859d-f6bbb57e9c96

* a bit more sophisticated
* now with actual view layers inside the windows
* implemented the resize modes (from Adis code)
* windows have resize handles and more correctly
clip the views inside
* bringing windows to front or sending them behind all others
* one active window, the others are inactive
* with and without focus follows mouse mode

* bugs:
- the region marked dirty when views are
resized is not correct yet

* todo:
- move the dirty region from being managed by the
desktop to being managed in each window (and being
local too)
- scrolling
- hiding/showing of windows and views

I plan to extend this to fully simulate asynchronous
drawing from clients, to see any problems before
using this in the real server one day.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15132 a95241bf-73f2-0310-859d-f6bbb57e9c96

Adi and I have had long talks about better approaches to clipping and we are convinced that a different design can significantly speed up the clipping processing in the root layer thread. This is a first prototype implementing the new ideas. Lots of features are missing yet, but Adi asked me to commit it now, so that we can both continue to work on it. The purpose of the new design is to significantly reduce the computations during an atomic clipping update, and also to scale much better with many more open windows.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15101 a95241bf-73f2-0310-859d-f6bbb57e9c96