now directly banging the hardware by using a cloned accelerant, soon to be ported to the app_server test environment. Unfortunately deadlocks most of the time when quitting...

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

not in a nice way, but I hope to have fixed the deadlocking problems on program exit

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

with the new design, there is always only one redraw message in the WindowLayers message queue, therefor, ReadLockWithTimeout() is no longer needed, removed RWLocker again as MultiLocker suits our needs.

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

now doing without a global dirty region, and it seems it gained a little speed too, should be easier now to make the multi locker work

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

* 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

now directly banging the hardware by using a cloned accelerant, soon to be ported to the app_server test environment. Unfortunately deadlocks most of the time when quitting...

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

not in a nice way, but I hope to have fixed the deadlocking problems on program exit

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

with the new design, there is always only one redraw message in the WindowLayers message queue, therefor, ReadLockWithTimeout() is no longer needed, removed RWLocker again as MultiLocker suits our needs.

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

now doing without a global dirty region, and it seems it gained a little speed too, should be easier now to make the multi locker work

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

* 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