History log of /haiku/src/servers/app/BitmapManager.cpp
Revision Date Author Comments
# 16d463ae 16-Jul-2019 Adrien Destugues <pulkomandy@pulkomandy.tk>

PVS V501: redundant checks

There are some more in telnetd and agg but I'm not sure if they are
intentional, the code is so ugly there.

Change-Id: I9cc2bf8a919c3b1d6c68f2ded8622730497b0f91
Reviewed-on: https://review.haiku-os.org/c/1598
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>


# 577f5876 21-Jan-2012 czeidler <haiku@clemens-zeidler.de>

Make it possible to reconnect BBitmap to the app_server.
* maintain a list of all BBitmaps
* refactor the client memory allocator class, its possible now to just clone existing client area


# 174a961e 27-Dec-2010 Michael Lotz <mmlr@mlotz.ch>

CID 5885: Resource leak in error case.


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


# 4b0459b2 04-Nov-2009 Axel Dörfler <axeld@pinc-software.de>

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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


# 85a7877f 04-Nov-2009 Axel Dörfler <axeld@pinc-software.de>

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


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


# 0eed9183 20-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Rewrote screen configuration management: VirtualScreen doesn't have anything
to do with the configurations now, instead, there is a separated
ScreenConfigurations class that maintains all known screen_configurations
per workspace (and the Workspace::Private class has two of them, one for the
current modes, one for the stored modes).
* Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those.
* Getting and setting of anything else than the current screen is now supported.
* This change also fixes that a temporarily set screen mode was not being
restored on workspace switch.
* Also, the Deskbar now seems to have the wrong location a lot, which is
something that should be easily fixable therefore. I will look into this next.
* Got rid of the unhandy screen_id structure server side, and in BPrivateScreen;
we now just use an int32 - the next API break should definitely replace the
screen_id with a simple typedef.
* Some cleanup.


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


# 219bd33f 17-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Deleted overlays were never removed from the fOverlays list, instead they were
added another time (copy&paste bug). This caused #3282.
* Added optional tracing output to Overlay.cpp.


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


# 1e855c37 12-Apr-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers).
* Added missing header for mountvolume.


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


# dcd70f0e 26-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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


# 417889ce 10-Mar-2008 Stephan Aßmus <superstippi@gmx.de>

* Handle clearing to white on the client. This also makes sure that bitmaps are
cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK).
* Check the allocation of the BWindow in BBitmap for view accepting bitmaps.


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


# 95baf312 11-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* view accepting bitmaps are now cleared to white


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


# ef636873 28-Jun-2007 Axel Dörfler <axeld@pinc-software.de>

Fixed the overlay I accidently broke with the last commit - sometimes, but only
sometimes, testing seems like a good idea 8-)


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


# 117b384e 27-Jun-2007 Axel Dörfler <axeld@pinc-software.de>

* Implemented the overlay suspend/resume protocol on mode changes; not really tested
yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL.
* The downside is that many more classes now know of each other.
* Cleaned up the work divided between the BitmapManager and the Overlay class.
* Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to
the ServerApp's bitmap list.


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


# 0ac013e6 23-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
source file.
* An overlay is now also hidden in case its is removed from the window.


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


# 21c8c925 22-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* With Rudolf's information about relocating overlays, I changed the way memory
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.


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


# 68bf2de5 21-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.


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


# 37b502f2 21-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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


# 4ec7e197 19-Mar-2006 Stephan Aßmus <superstippi@gmx.de>

* fixed filling B_CMAP8 bitmaps with white (255 was the wrong
color index)


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


# 9a44fdc9 18-Mar-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


# 8b41c213 03-Mar-2006 Stephan Aßmus <superstippi@gmx.de>

* B_BITMAP_WILL_OVERLAY bitmaps are currently not
supported. (makes VLC run without changes)
* B_BITMAP_CLEAR_TO_WHITE causes the server to
clear the bitmap to white... :-)
* removed weird comment


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


# 55fd3336 29-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

* Fixed a bug in ServerApp: when a ServerWindow would take too long to quit,
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.


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


# 4acb99b6 29-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Implemented reference counting of ServerBitmaps, made constructor and destructor private,
as only the BitmapManager class is allowed to call them.


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


# e83820ed 07-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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


# be05d56c 14-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


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


# 758b1d0e 12-Nov-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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


# 0ec4af22 23-Jun-2005 Axel Dörfler <axeld@pinc-software.de>

Improved AreaPool to have an initial size as well as well as a name that is
used for new area.
MemPool::AddToPool() now gracefully deals with NULL pointers (or a size of 0).
BitmapManager was deleting the area it transferred to AreaPool before - it
no longer needs an extra area, though.
Minor other cleanup.


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


# b5436616 23-Jun-2005 Axel Dörfler <axeld@pinc-software.de>

Fixed some style related functions and other oddities in FontServer.
Also applied our style guide on that class.
Renamed some public globals to match our style guide.
Made BitmapManager inherit from BLocker instead of duplicating its
functionality (incorrectly, did not check for B_INTERRUPTED) locally.
Some more cleanup.


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


# c69d4b27 23-Jun-2005 Stephan Aßmus <superstippi@gmx.de>

clean up, bug fixes and more robustness

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


# 33bbe223 24-Mar-2005 Axel Dörfler <axeld@pinc-software.de>

Moved app_server files to app/.


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


# 577f58763be348b31493bc7266dd9f62c4e40f02 21-Jan-2012 czeidler <haiku@clemens-zeidler.de>

Make it possible to reconnect BBitmap to the app_server.
* maintain a list of all BBitmaps
* refactor the client memory allocator class, its possible now to just clone existing client area


# 174a961e22902a5723425e621e801f9980055fa1 27-Dec-2010 Michael Lotz <mmlr@mlotz.ch>

CID 5885: Resource leak in error case.


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


# 4b0459b2eef38f07b8c0c4426860dccb61a1134a 04-Nov-2009 Axel Dörfler <axeld@pinc-software.de>

* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of
roling its own solution.
* Also removed BitmapManager::DeleteBitmap() - you only call
ServerBitmap::RemoveReference(), and that one will notify the manager if
needed.
* Some more cleanup.


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


# 85a7877f80790d60e084ba8d7e6f1ae5f9a6fee1 04-Nov-2009 Axel Dörfler <axeld@pinc-software.de>

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


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


# 0eed9183061a7763972bc2589f9c43489cd078ab 20-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Rewrote screen configuration management: VirtualScreen doesn't have anything
to do with the configurations now, instead, there is a separated
ScreenConfigurations class that maintains all known screen_configurations
per workspace (and the Workspace::Private class has two of them, one for the
current modes, one for the stored modes).
* Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those.
* Getting and setting of anything else than the current screen is now supported.
* This change also fixes that a temporarily set screen mode was not being
restored on workspace switch.
* Also, the Deskbar now seems to have the wrong location a lot, which is
something that should be easily fixable therefore. I will look into this next.
* Got rid of the unhandy screen_id structure server side, and in BPrivateScreen;
we now just use an int32 - the next API break should definitely replace the
screen_id with a simple typedef.
* Some cleanup.


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


# 219bd33f29c86db8275ab13690c02f9a63ebaf59 17-Aug-2009 Axel Dörfler <axeld@pinc-software.de>

* Deleted overlays were never removed from the fOverlays list, instead they were
added another time (copy&paste bug). This caused #3282.
* Added optional tracing output to Overlay.cpp.


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


# 1e855c376c4f785f926c0c4d4d08c827c05da643 12-Apr-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* Patch by Fredrik Ekdahl: gcc 4 build fixes (missing headers).
* Added missing header for mountvolume.


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


# dcd70f0e3967582a60a8012431246a3632bf65de 26-Jul-2008 Stephan Aßmus <superstippi@gmx.de>

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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


# 417889ced83de5a38e8d9dccdee23af9a1e770ff 10-Mar-2008 Stephan Aßmus <superstippi@gmx.de>

* Handle clearing to white on the client. This also makes sure that bitmaps are
cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK).
* Check the allocation of the BWindow in BBitmap for view accepting bitmaps.


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


# 95baf31294ee9c7fb9e2cf768422c10a2a74a42a 11-Aug-2007 Stephan Aßmus <superstippi@gmx.de>

* view accepting bitmaps are now cleared to white


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


# ef636873ad1bc7dca65bcd531b3e24a3e0beea35 28-Jun-2007 Axel Dörfler <axeld@pinc-software.de>

Fixed the overlay I accidently broke with the last commit - sometimes, but only
sometimes, testing seems like a good idea 8-)


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


# 117b384e5ea73689b02264424911b0848be47962 27-Jun-2007 Axel Dörfler <axeld@pinc-software.de>

* Implemented the overlay suspend/resume protocol on mode changes; not really tested
yet. Also, BBitmap::LockBits() should probably fail when the Bits() are NULL.
* The downside is that many more classes now know of each other.
* Cleaned up the work divided between the BitmapManager and the Overlay class.
* Fixed a memory leak in AS_CREATE_BITMAP in case the bitmap could not be added to
the ServerApp's bitmap list.


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


# 0ac013e66f75c5733fcd6bca47300d126b293279 23-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* Some refactoring: renamed OverlayCookie to Overlay and put it in its own
source file.
* An overlay is now also hidden in case its is removed from the window.


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


# 21c8c925d834845b599781b72192b10befc68ec0 22-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* With Rudolf's information about relocating overlays, I changed the way memory
is managed for those bitmaps:
- the shared client memory mechanism is used to allocate a small overlay_client_data
structure that contains the actual buffer and a semaphore that you have acquire in
order to access it.
- LockBits()/UnlockBits() now have a function: you need to call them before accessing
the overlay buffer, and you need to keep that lock until you're done with it.
* The overlay cookie is now an extra member of the ServerBitmap class.
* Removed fInitialized from ServerBitmap - IsValid() now just checks the buffer associated
with the bitmap.
* ViewLayer::Draw() will now handle overlay bitmaps specially and will draw the overlay
color instead of any contents (this is currently in ugly pink, but will become some
dark color later on).
* All what's missing from actually being able to use overlays now is to configure
them so that they are shown on screen. VLC will now show an empty pink window when
overlay video is enabled.


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


# 68bf2de593715bb0f43a0fbbd988bf9f2d651976 21-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

* Refined overlay support a bit: we now allow as many overlay bitmaps to be
created as the graphics driver does.
* Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected.
* We're no longer using the B_OVERLAY_COUNT hook anymore - that one really
looks like a misconception to me; I don't see how it can be useful.


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


# 37b502f28bf22293b4b060e8577e491d1c299ca8 21-Apr-2006 Axel Dörfler <axeld@pinc-software.de>

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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


# 4ec7e19751e39af9e4db1b4bfabbea3623143d1e 19-Mar-2006 Stephan Aßmus <superstippi@gmx.de>

* fixed filling B_CMAP8 bitmaps with white (255 was the wrong
color index)


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


# 9a44fdc97c4c91b6be039ac5125a618c8fd268cc 18-Mar-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


# 8b41c21369ab2de688d6369fafc532a52de0d9a2 03-Mar-2006 Stephan Aßmus <superstippi@gmx.de>

* B_BITMAP_WILL_OVERLAY bitmaps are currently not
supported. (makes VLC run without changes)
* B_BITMAP_CLEAR_TO_WHITE causes the server to
clear the bitmap to white... :-)
* removed weird comment


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


# 55fd3336b6bb6e3407377196f70991a01d081eda 29-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

* Fixed a bug in ServerApp: when a ServerWindow would take too long to quit,
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.


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


# 4acb99b60f38da581d1409e9ffd3c4ab8fe95041 29-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Implemented reference counting of ServerBitmaps, made constructor and destructor private,
as only the BitmapManager class is allowed to call them.


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


# e83820ed5720395d39a1ff809991b4fd76326548 07-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk.
Also fixed Jamfile for the test environment.


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


# be05d56c7eea834b5983ba3411d79fabd8b616b7 14-Nov-2005 Axel Dörfler <axeld@pinc-software.de>

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


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


# 758b1d0e05fe1042cce6e00d194a147802d4f9be 12-Nov-2005 Ingo Weinhold <ingo_weinhold@gmx.de>

Fixes that make Haiku build with gcc 4. Mainly out of the following
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.



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


# 0ec4af22334b9ded101a81c7c25886ecc84a6129 23-Jun-2005 Axel Dörfler <axeld@pinc-software.de>

Improved AreaPool to have an initial size as well as well as a name that is
used for new area.
MemPool::AddToPool() now gracefully deals with NULL pointers (or a size of 0).
BitmapManager was deleting the area it transferred to AreaPool before - it
no longer needs an extra area, though.
Minor other cleanup.


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


# b5436616a3528ac13645a3e73065474ef988c107 23-Jun-2005 Axel Dörfler <axeld@pinc-software.de>

Fixed some style related functions and other oddities in FontServer.
Also applied our style guide on that class.
Renamed some public globals to match our style guide.
Made BitmapManager inherit from BLocker instead of duplicating its
functionality (incorrectly, did not check for B_INTERRUPTED) locally.
Some more cleanup.


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


# c69d4b271962c1f20f7c9e28441db0dea540004d 23-Jun-2005 Stephan Aßmus <superstippi@gmx.de>

clean up, bug fixes and more robustness

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


# 33bbe223914093509b4bc56bea8a90c81af80a37 24-Mar-2005 Axel Dörfler <axeld@pinc-software.de>

Moved app_server files to app/.


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