2005-06-24 07:31:41 +04:00
|
|
|
/*
|
2007-06-27 15:29:20 +04:00
|
|
|
* Copyright 2001-2007, Haiku.
|
2005-06-24 07:31:41 +04:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* DarkWyrm <bpmagic@columbus.rr.com>
|
2006-04-22 20:41:12 +04:00
|
|
|
* Axel Dörfler, axeld@pinc-software.de
|
2005-06-24 07:31:41 +04:00
|
|
|
*/
|
|
|
|
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
/*!
|
|
|
|
Whenever a ServerBitmap associated with a client-side BBitmap needs to be
|
|
|
|
created or destroyed, the BitmapManager needs to handle it. It takes care of
|
|
|
|
all memory management related to them.
|
|
|
|
*/
|
2005-06-24 07:31:41 +04:00
|
|
|
|
2005-06-24 03:14:40 +04:00
|
|
|
|
|
|
|
#include "BitmapManager.h"
|
2006-04-22 00:14:41 +04:00
|
|
|
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
#include "ClientMemoryAllocator.h"
|
2006-04-22 00:14:41 +04:00
|
|
|
#include "HWInterface.h"
|
2006-04-23 19:45:35 +04:00
|
|
|
#include "Overlay.h"
|
2007-06-27 15:29:20 +04:00
|
|
|
#include "ServerApp.h"
|
2005-11-14 22:46:20 +03:00
|
|
|
#include "ServerBitmap.h"
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
#include "ServerProtocol.h"
|
2005-11-14 22:46:20 +03:00
|
|
|
#include "ServerTokenSpace.h"
|
2003-02-13 03:03:31 +03:00
|
|
|
|
2006-04-22 20:41:12 +04:00
|
|
|
#include <BitmapPrivate.h>
|
2007-06-27 15:29:20 +04:00
|
|
|
#include <ObjectList.h>
|
2006-04-22 00:14:41 +04:00
|
|
|
#include <video_overlay.h>
|
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
#include <AppDefs.h>
|
2006-04-22 00:14:41 +04:00
|
|
|
#include <Autolock.h>
|
|
|
|
#include <Bitmap.h>
|
2007-06-27 15:29:20 +04:00
|
|
|
#include <Message.h>
|
2006-04-22 00:14:41 +04:00
|
|
|
|
|
|
|
#include <new>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
2005-11-13 02:27:14 +03:00
|
|
|
using std::nothrow;
|
2005-06-24 07:31:41 +04:00
|
|
|
|
2005-11-14 22:46:20 +03:00
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
//! The one and only bitmap manager for the server, created by the AppServer
|
2005-06-24 07:31:41 +04:00
|
|
|
BitmapManager *gBitmapManager = NULL;
|
2003-02-20 23:14:57 +03:00
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
|
|
|
|
int
|
|
|
|
compare_app_pointer(const ServerApp* a, const ServerApp* b)
|
|
|
|
{
|
|
|
|
return (addr_t)b - (addr_t)b;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// #pragma mark -
|
2003-02-13 03:03:31 +03:00
|
|
|
|
2005-11-14 22:46:20 +03:00
|
|
|
|
2003-02-17 19:24:27 +03:00
|
|
|
//! Sets up stuff to be ready to allocate space for bitmaps
|
2005-06-24 03:14:40 +04:00
|
|
|
BitmapManager::BitmapManager()
|
2005-06-24 08:01:16 +04:00
|
|
|
:
|
|
|
|
fBitmapList(1024),
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
fLock("BitmapManager Lock")
|
2005-06-24 03:14:40 +04:00
|
|
|
{
|
2003-02-13 03:03:31 +03:00
|
|
|
}
|
|
|
|
|
2005-11-14 22:46:20 +03:00
|
|
|
|
2003-02-17 19:24:27 +03:00
|
|
|
//! Deallocates everything associated with the manager
|
2005-06-24 03:14:40 +04:00
|
|
|
BitmapManager::~BitmapManager()
|
2003-02-13 03:03:31 +03:00
|
|
|
{
|
2005-06-24 03:14:40 +04:00
|
|
|
int32 count = fBitmapList.CountItems();
|
|
|
|
for (int32 i = 0; i < count; i++) {
|
|
|
|
if (ServerBitmap* bitmap = (ServerBitmap*)fBitmapList.ItemAt(i)) {
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
if (bitmap->AllocationCookie() != NULL)
|
|
|
|
debugger("We're not supposed to keep our cookies...");
|
|
|
|
|
2005-06-24 03:14:40 +04:00
|
|
|
delete bitmap;
|
2003-02-13 03:03:31 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-11-14 22:46:20 +03:00
|
|
|
|
2003-02-17 19:24:27 +03:00
|
|
|
/*!
|
|
|
|
\brief Allocates a new ServerBitmap.
|
|
|
|
\param bounds Size of the bitmap
|
|
|
|
\param space Color space of the bitmap
|
|
|
|
\param flags Bitmap flags as defined in Bitmap.h
|
2005-06-24 03:14:40 +04:00
|
|
|
\param bytesPerRow Number of bytes per row.
|
2003-02-17 19:24:27 +03:00
|
|
|
\param screen Screen id of the screen associated with it. Unused.
|
|
|
|
\return A new ServerBitmap or NULL if unable to allocate one.
|
|
|
|
*/
|
2005-06-24 03:14:40 +04:00
|
|
|
ServerBitmap*
|
2007-06-27 15:29:20 +04:00
|
|
|
BitmapManager::CreateBitmap(ClientMemoryAllocator* allocator,
|
|
|
|
HWInterface& hwInterface, BRect bounds, color_space space, int32 flags,
|
|
|
|
int32 bytesPerRow, screen_id screen, uint8* _allocationFlags)
|
2003-02-13 03:03:31 +03:00
|
|
|
{
|
2005-06-24 07:31:41 +04:00
|
|
|
BAutolock locker(fLock);
|
2005-06-24 03:14:40 +04:00
|
|
|
|
2005-06-24 07:31:41 +04:00
|
|
|
if (!locker.IsLocked())
|
|
|
|
return NULL;
|
|
|
|
|
2006-04-22 01:13:11 +04:00
|
|
|
overlay_token overlayToken = NULL;
|
|
|
|
|
2006-04-22 00:14:41 +04:00
|
|
|
if (flags & B_BITMAP_WILL_OVERLAY) {
|
2006-04-22 01:13:11 +04:00
|
|
|
if (!hwInterface.CheckOverlayRestrictions(bounds.IntegerWidth() + 1,
|
|
|
|
bounds.IntegerHeight() + 1, space))
|
2006-04-22 00:14:41 +04:00
|
|
|
return NULL;
|
|
|
|
|
2006-04-22 01:13:11 +04:00
|
|
|
if (flags & B_BITMAP_RESERVE_OVERLAY_CHANNEL) {
|
|
|
|
overlayToken = hwInterface.AcquireOverlayChannel();
|
|
|
|
if (overlayToken == NULL)
|
|
|
|
return NULL;
|
|
|
|
}
|
2006-04-22 00:14:41 +04:00
|
|
|
}
|
2006-03-03 23:24:13 +03:00
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
ServerBitmap* bitmap = new(nothrow) ServerBitmap(bounds, space, flags,
|
|
|
|
bytesPerRow);
|
2006-04-22 00:14:41 +04:00
|
|
|
if (bitmap == NULL) {
|
2006-04-22 01:13:11 +04:00
|
|
|
if (overlayToken != NULL)
|
|
|
|
hwInterface.ReleaseOverlayChannel(overlayToken);
|
2006-04-22 00:14:41 +04:00
|
|
|
|
2005-06-24 07:31:41 +04:00
|
|
|
return NULL;
|
2006-04-22 00:14:41 +04:00
|
|
|
}
|
2005-06-24 07:31:41 +04:00
|
|
|
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
void* cookie = NULL;
|
|
|
|
uint8* buffer = NULL;
|
|
|
|
|
2006-04-22 00:14:41 +04:00
|
|
|
if (flags & B_BITMAP_WILL_OVERLAY) {
|
2007-06-27 15:29:20 +04:00
|
|
|
Overlay* overlay = new (std::nothrow) Overlay(hwInterface, bitmap,
|
|
|
|
overlayToken);
|
2006-04-22 00:14:41 +04:00
|
|
|
|
2006-04-22 20:41:12 +04:00
|
|
|
overlay_client_data* clientData = NULL;
|
|
|
|
bool newArea = false;
|
|
|
|
|
2006-04-23 19:45:35 +04:00
|
|
|
if (overlay != NULL && overlay->InitCheck() == B_OK) {
|
2006-04-22 20:41:12 +04:00
|
|
|
// allocate client memory to communicate the overlay semaphore
|
|
|
|
// and buffer location to the BBitmap
|
|
|
|
cookie = allocator->Allocate(sizeof(overlay_client_data),
|
|
|
|
(void**)&clientData, newArea);
|
2006-04-22 00:14:41 +04:00
|
|
|
}
|
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
if (cookie != NULL) {
|
|
|
|
overlay->SetClientData(clientData);
|
2006-04-22 01:13:11 +04:00
|
|
|
|
2006-04-22 20:41:12 +04:00
|
|
|
bitmap->fAllocator = allocator;
|
|
|
|
bitmap->fAllocationCookie = cookie;
|
2006-04-23 19:45:35 +04:00
|
|
|
bitmap->SetOverlay(overlay);
|
2007-06-29 00:05:39 +04:00
|
|
|
bitmap->fBytesPerRow = overlay->OverlayBuffer()->bytes_per_row;
|
2006-04-22 00:14:41 +04:00
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
buffer = (uint8*)overlay->OverlayBuffer()->buffer;
|
2006-04-22 20:41:12 +04:00
|
|
|
if (_allocationFlags)
|
|
|
|
*_allocationFlags = kFramebuffer | (newArea ? kNewAllocatorArea : 0);
|
2006-04-22 01:13:11 +04:00
|
|
|
} else {
|
2006-04-23 19:45:35 +04:00
|
|
|
delete overlay;
|
2006-04-22 20:41:12 +04:00
|
|
|
allocator->Free(cookie);
|
2006-04-22 01:13:11 +04:00
|
|
|
}
|
2006-04-22 00:14:41 +04:00
|
|
|
} else if (allocator != NULL) {
|
2006-04-22 20:41:12 +04:00
|
|
|
// standard bitmaps
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
bool newArea;
|
|
|
|
cookie = allocator->Allocate(bitmap->BitsLength(), (void**)&buffer, newArea);
|
|
|
|
if (cookie != NULL) {
|
|
|
|
bitmap->fAllocator = allocator;
|
|
|
|
bitmap->fAllocationCookie = cookie;
|
|
|
|
|
2006-04-22 20:41:12 +04:00
|
|
|
if (_allocationFlags)
|
|
|
|
*_allocationFlags = kAllocator | (newArea ? kNewAllocatorArea : 0);
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
}
|
|
|
|
} else {
|
2006-04-22 20:41:12 +04:00
|
|
|
// server side only bitmaps
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
buffer = (uint8*)malloc(bitmap->BitsLength());
|
|
|
|
if (buffer != NULL) {
|
|
|
|
bitmap->fAllocator = NULL;
|
|
|
|
bitmap->fAllocationCookie = NULL;
|
|
|
|
|
2006-04-22 20:41:12 +04:00
|
|
|
if (_allocationFlags)
|
|
|
|
*_allocationFlags = kHeap;
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
}
|
|
|
|
}
|
2005-06-24 07:31:41 +04:00
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
bool success = false;
|
|
|
|
if (buffer != NULL) {
|
|
|
|
success = fBitmapList.AddItem(bitmap);
|
|
|
|
if (success && bitmap->Overlay() != NULL) {
|
|
|
|
success = fOverlays.AddItem(bitmap);
|
|
|
|
if (!success)
|
|
|
|
fBitmapList.RemoveItem(bitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (success) {
|
2005-06-24 07:31:41 +04:00
|
|
|
bitmap->fBuffer = buffer;
|
2005-11-14 22:46:20 +03:00
|
|
|
bitmap->fToken = gTokenSpace.NewToken(kBitmapToken, bitmap);
|
2008-03-10 13:51:56 +03:00
|
|
|
// NOTE: the client handles clearing to white in case the flags
|
|
|
|
// indicate this is needed
|
2005-06-24 07:31:41 +04:00
|
|
|
} else {
|
|
|
|
// Allocation failed for buffer or bitmap list
|
|
|
|
delete bitmap;
|
|
|
|
bitmap = NULL;
|
2003-02-13 03:03:31 +03:00
|
|
|
}
|
2005-06-24 07:31:41 +04:00
|
|
|
|
2005-06-24 03:14:40 +04:00
|
|
|
return bitmap;
|
2003-02-13 03:03:31 +03:00
|
|
|
}
|
|
|
|
|
2005-11-14 22:46:20 +03:00
|
|
|
|
2003-02-17 19:24:27 +03:00
|
|
|
/*!
|
|
|
|
\brief Deletes a ServerBitmap.
|
|
|
|
\param bitmap The bitmap to delete
|
|
|
|
*/
|
2005-06-24 03:14:40 +04:00
|
|
|
void
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
BitmapManager::DeleteBitmap(ServerBitmap* bitmap)
|
2003-02-13 03:03:31 +03:00
|
|
|
{
|
2005-12-29 20:40:18 +03:00
|
|
|
if (bitmap == NULL || !bitmap->_Release()) {
|
2005-12-29 18:36:18 +03:00
|
|
|
// there are other references to this bitmap, we don't have to delete it yet
|
|
|
|
return;
|
|
|
|
}
|
2005-06-24 07:31:41 +04:00
|
|
|
|
2005-12-29 18:36:18 +03:00
|
|
|
BAutolock locker(fLock);
|
2005-06-24 07:31:41 +04:00
|
|
|
if (!locker.IsLocked())
|
|
|
|
return;
|
|
|
|
|
2007-06-27 15:29:20 +04:00
|
|
|
if (bitmap->Overlay() != NULL)
|
|
|
|
fOverlays.AddItem(bitmap);
|
|
|
|
|
* 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
2006-03-18 16:43:26 +03:00
|
|
|
if (fBitmapList.RemoveItem(bitmap))
|
2005-06-24 07:31:41 +04:00
|
|
|
delete bitmap;
|
2003-02-13 03:03:31 +03:00
|
|
|
}
|
2007-06-27 15:29:20 +04:00
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
BitmapManager::SuspendOverlays()
|
|
|
|
{
|
|
|
|
BAutolock locker(fLock);
|
|
|
|
if (!locker.IsLocked())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// first, tell all applications owning an overlay to release their locks
|
|
|
|
|
|
|
|
BObjectList<ServerApp> apps;
|
|
|
|
for (int32 i = 0; i < fOverlays.CountItems(); i++) {
|
|
|
|
ServerBitmap* bitmap = (ServerBitmap*)fOverlays.ItemAt(i);
|
|
|
|
apps.BinaryInsert(bitmap->Owner(), &compare_app_pointer);
|
|
|
|
}
|
|
|
|
for (int32 i = 0; i < apps.CountItems(); i++) {
|
|
|
|
BMessage notify(B_RELEASE_OVERLAY_LOCK);
|
|
|
|
apps.ItemAt(i)->SendMessageToClient(¬ify);
|
|
|
|
}
|
|
|
|
|
|
|
|
// suspend overlays
|
|
|
|
|
|
|
|
for (int32 i = 0; i < fOverlays.CountItems(); i++) {
|
|
|
|
ServerBitmap* bitmap = (ServerBitmap*)fOverlays.ItemAt(i);
|
|
|
|
bitmap->Overlay()->Suspend(bitmap, false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
BitmapManager::ResumeOverlays()
|
|
|
|
{
|
|
|
|
BAutolock locker(fLock);
|
|
|
|
if (!locker.IsLocked())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// first, tell all applications owning an overlay that
|
|
|
|
// they can reacquire their locks
|
|
|
|
|
|
|
|
BObjectList<ServerApp> apps;
|
|
|
|
for (int32 i = 0; i < fOverlays.CountItems(); i++) {
|
|
|
|
ServerBitmap* bitmap = (ServerBitmap*)fOverlays.ItemAt(i);
|
|
|
|
apps.BinaryInsert(bitmap->Owner(), &compare_app_pointer);
|
|
|
|
}
|
|
|
|
for (int32 i = 0; i < apps.CountItems(); i++) {
|
|
|
|
BMessage notify(B_RELEASE_OVERLAY_LOCK);
|
|
|
|
apps.ItemAt(i)->SendMessageToClient(¬ify);
|
|
|
|
}
|
|
|
|
|
|
|
|
// resume overlays
|
|
|
|
|
|
|
|
for (int32 i = 0; i < fOverlays.CountItems(); i++) {
|
|
|
|
ServerBitmap* bitmap = (ServerBitmap*)fOverlays.ItemAt(i);
|
|
|
|
|
|
|
|
bitmap->Overlay()->Resume(bitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|