I have no idea anymore what I was messing with here, but it looks interesting.


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

added libbeadapter.so (used by the storage kit and the haiku regisrar) to the test libs, it just went unnoticed before

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

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

I couldn't resist playing some more with ezprof. I don't know if I can trust it's results though, revealing as they are. Somebody should explain to me why forgetting a return *this; in an operator= method works in the first place, and why it results in the constructor being called.

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

I did some profiling using Daniel Reinholds ezprof, which is quite nice actually. I optimized a bit, without spending too much time on that yet, and now the clipping is on average 7 times faster than the current app_server (the time spend in the root layer thread)

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

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

stress testing. It shows that for 40 open windows, the newerClipping design takes 3.5 times less time in the root layer thread compared to the newClipping design. On average, it is about 8.7 times faster. The goal of the redesign, to move the heavier computation from the root layer thread into each window thread, seems achieved, since even with 100 open windows, moving a window does not start any lagging. By removing the global dirty region in Desktop, I think this can be further improved.

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

I have no idea anymore what I was messing with here, but it looks interesting.


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

added libbeadapter.so (used by the storage kit and the haiku regisrar) to the test libs, it just went unnoticed before

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

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

I couldn't resist playing some more with ezprof. I don't know if I can trust it's results though, revealing as they are. Somebody should explain to me why forgetting a return *this; in an operator= method works in the first place, and why it results in the constructor being called.

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

I did some profiling using Daniel Reinholds ezprof, which is quite nice actually. I optimized a bit, without spending too much time on that yet, and now the clipping is on average 7 times faster than the current app_server (the time spend in the root layer thread)

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

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

stress testing. It shows that for 40 open windows, the newerClipping design takes 3.5 times less time in the root layer thread compared to the newClipping design. On average, it is about 8.7 times faster. The goal of the redesign, to move the heavier computation from the root layer thread into each window thread, seems achieved, since even with 100 open windows, moving a window does not start any lagging. By removing the global dirty region in Desktop, I think this can be further improved.

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