#
e76d86d5 |
|
09-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
7fd1af6f |
|
30-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
312345bc |
|
29-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
4dd89c69 |
|
29-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
ff89d51e |
|
25-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
bef1ed93 |
|
24-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
e76d86d5dd9a32639a877abbd1ffb318c040c720 |
|
09-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
7fd1af6f040618119df7874f8be3a61641fc76c9 |
|
30-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
312345bcb18ee884afce4c6cc9b9cf0cbafbbe87 |
|
29-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
4dd89c69035045bb0d7aa5a604d8d37bfa2cf3f6 |
|
29-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
ff89d51e02ce7dcd6177bdbf847457503112a3b8 |
|
25-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
bef1ed93e146a1bed4156b62f743e8c9cf83485c |
|
24-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|