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
|
|
|
* Copyright 2001-2006, Haiku.
|
2005-06-24 07:31:41 +04:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* DarkWyrm <bpmagic@columbus.rr.com>
|
|
|
|
*/
|
|
|
|
|
* 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
|
|
|
/*!
|
|
|
|
Handler for allocating and freeing area memory for BBitmaps
|
|
|
|
on the server side. Utilizes the BGET pool allocator.
|
|
|
|
|
|
|
|
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"
|
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 00:14:41 +04:00
|
|
|
#include <video_overlay.h>
|
|
|
|
|
|
|
|
#include <Autolock.h>
|
|
|
|
#include <Bitmap.h>
|
|
|
|
|
|
|
|
#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
|
|
|
|
2003-02-20 23:14:57 +03:00
|
|
|
//! The bitmap allocator for the server. Memory is allocated/freed by the AppServer class
|
2005-06-24 07:31:41 +04:00
|
|
|
BitmapManager *gBitmapManager = NULL;
|
2003-02-20 23:14:57 +03:00
|
|
|
|
2003-02-17 19:24:27 +03:00
|
|
|
//! Number of bytes to allocate to each area used for bitmap storage
|
2005-12-08 15:41:19 +03:00
|
|
|
#define BITMAP_AREA_SIZE B_PAGE_SIZE * 16
|
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*
|
2006-04-22 00:14:41 +04:00
|
|
|
BitmapManager::CreateBitmap(ClientMemoryAllocator* allocator, HWInterface& hwInterface,
|
|
|
|
BRect bounds, color_space space, int32 flags, int32 bytesPerRow, screen_id screen,
|
* 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
|
|
|
int8* _allocationType)
|
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
|
|
|
|
2005-06-24 07:31:41 +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) {
|
|
|
|
OverlayCookie* overlayCookie = new (std::nothrow) OverlayCookie(hwInterface);
|
|
|
|
const overlay_buffer* overlayBuffer = NULL;
|
|
|
|
|
|
|
|
if (overlayCookie != NULL) {
|
|
|
|
overlayBuffer = hwInterface.AllocateOverlayBuffer(bitmap->Width(),
|
|
|
|
bitmap->Height(), space);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (overlayBuffer != NULL) {
|
|
|
|
overlayCookie->SetOverlayBuffer(overlayBuffer);
|
2006-04-22 01:13:11 +04:00
|
|
|
overlayCookie->SetOverlayToken(overlayToken);
|
|
|
|
|
2006-04-22 00:14:41 +04:00
|
|
|
bitmap->fAllocationCookie = overlayCookie;
|
|
|
|
bitmap->fBytesPerRow = overlayBuffer->bytes_per_row;
|
|
|
|
|
|
|
|
buffer = (uint8*)overlayBuffer->buffer;
|
|
|
|
if (_allocationType)
|
|
|
|
*_allocationType = kFramebuffer;
|
2006-04-22 01:13:11 +04:00
|
|
|
} else {
|
|
|
|
hwInterface.ReleaseOverlayChannel(overlayToken);
|
2006-04-22 00:14:41 +04:00
|
|
|
delete overlayCookie;
|
2006-04-22 01:13:11 +04:00
|
|
|
}
|
2006-04-22 00:14:41 +04:00
|
|
|
} else if (allocator != NULL) {
|
* 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;
|
|
|
|
|
|
|
|
if (_allocationType)
|
|
|
|
*_allocationType = newArea ? kNewAllocatorArea : kAllocator;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
buffer = (uint8*)malloc(bitmap->BitsLength());
|
|
|
|
if (buffer != NULL) {
|
|
|
|
bitmap->fAllocator = NULL;
|
|
|
|
bitmap->fAllocationCookie = NULL;
|
|
|
|
|
|
|
|
if (_allocationType)
|
|
|
|
*_allocationType = kHeap;
|
|
|
|
}
|
|
|
|
}
|
2005-06-24 07:31:41 +04:00
|
|
|
|
|
|
|
if (buffer && fBitmapList.AddItem(bitmap)) {
|
|
|
|
bitmap->fBuffer = buffer;
|
2005-11-14 22:46:20 +03:00
|
|
|
bitmap->fToken = gTokenSpace.NewToken(kBitmapToken, bitmap);
|
2005-06-24 07:31:41 +04:00
|
|
|
bitmap->fInitialized = true;
|
|
|
|
|
2006-03-03 23:24:13 +03:00
|
|
|
if (flags & B_BITMAP_CLEAR_TO_WHITE) {
|
2006-03-20 01:35:20 +03:00
|
|
|
if (space == B_CMAP8)
|
|
|
|
// "255" is the "transparent magic" index for B_CMAP8 bitmaps
|
|
|
|
memset(bitmap->Bits(), 65, bitmap->BitsLength());
|
|
|
|
else
|
|
|
|
// should work for most colorspaces
|
|
|
|
memset(bitmap->Bits(), 255, bitmap->BitsLength());
|
2006-03-03 23:24:13 +03:00
|
|
|
}
|
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;
|
|
|
|
|
* 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
|
|
|
}
|