implemented invalidation triggered from the client side. 20 clients each displaying an animation in one view at 25 fps leaves the new clipping unimpressed, everything is fluent, also during moving and resizing windows

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15275 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

* added a multi locker implementation from Ingo Weinhold,
which supports ReadLockWithTimeout()
* commented the code in many more places
* understood the problem of making the read/write locking
work: While it would be possible for each window to
remove the processed region from the global dirty region
in read lock mode (since it is guaranteed not remove
a region not intersecting with its own visible region),
multiple window threads can still not do this at the same
time, since BRegion itself is not threadsafe of course.
* I need to figure out a way for the window threads to be
able to access and modify all needed data in read only mode,
I think this means to divide the global dirty region into
each window again, so that each window thread can simply
clear its own dirty region instead of excluding it from
the global region. Yeah, that might work.


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

this fixes the bugs in the update session region enforcement during client drawing, there is only one bug left now: resized ViewLayers don't invalidate the correct regions (they don't take areas into account that are hidden because the parent is too small)

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

make client drawing slow again, made client drawing use B_OP_BLEND which shows problems with incorrect clipping during update sessions

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15161 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

implemented invalidation triggered from the client side. 20 clients each displaying an animation in one view at 25 fps leaves the new clipping unimpressed, everything is fluent, also during moving and resizing windows

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15275 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

* added a multi locker implementation from Ingo Weinhold,
which supports ReadLockWithTimeout()
* commented the code in many more places
* understood the problem of making the read/write locking
work: While it would be possible for each window to
remove the processed region from the global dirty region
in read lock mode (since it is guaranteed not remove
a region not intersecting with its own visible region),
multiple window threads can still not do this at the same
time, since BRegion itself is not threadsafe of course.
* I need to figure out a way for the window threads to be
able to access and modify all needed data in read only mode,
I think this means to divide the global dirty region into
each window again, so that each window thread can simply
clear its own dirty region instead of excluding it from
the global region. Yeah, that might work.


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

this fixes the bugs in the update session region enforcement during client drawing, there is only one bug left now: resized ViewLayers don't invalidate the correct regions (they don't take areas into account that are hidden because the parent is too small)

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

make client drawing slow again, made client drawing use B_OP_BLEND which shows problems with incorrect clipping during update sessions

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15161 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