| /haiku/headers/private/app/ |
| H A D | ServerMemoryAllocator.h | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ApplicationPrivate.h | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ServerProtocol.h | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/servers/app/ |
| H A D | ClientMemoryAllocator.h | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ServerCursor.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ClientMemoryAllocator.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | BitmapManager.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ServerBitmap.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ServerApp.h | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | Jamfile | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | ServerApp.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/kits/app/ |
| H A D | ServerMemoryAllocator.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | Jamfile | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | Message.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | Application.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/kits/interface/ |
| H A D | PrivateScreen.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | Bitmap.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| H A D | View.cpp | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
| /haiku/src/tests/servers/app/ |
| H A D | Jamfile | 9a44fdc97c4c91b6be039ac5125a618c8fd268cc Sat Mar 18 13:43:26 UTC 2006 Axel Dörfler <axeld@pinc-software.de> * Implemented a new client allocation method: instead of having all bitmaps of
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
|