#
60d30785 |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management fixes: use BReference Use BReference for more automated reference counting in app_server, fixing some use-after-free and other problems. Extracted from https://review.haiku-os.org/c/haiku/+/2695 Change-Id: I141bb248229405896b29feff3338447f7257b0b4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
83e36298 |
|
27-Dec-2010 |
Michael Lotz <mmlr@mlotz.ch> |
CID 2977: Use the array delete operator. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39970 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
|
#
19e179ca |
|
19-Jun-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Moved the implementation of SetViewCursor from the thread of the window of the view into the application thread. This solves the race condition with asynchronous SetViewCursor and deleting the cursor immediately afterwards for real. * The ServerApp now requires a reference to the current cursor, just in case... * Added TODOs for caching the BView token, it's currently resolved for every single BView call that talks to the server... not good! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31133 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bbe2597f |
|
13-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
CID 18 and CID 19: Fix leaking the cursor data. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27487 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c6f9f65d |
|
03-Jan-2007 |
Axel Dörfler <axeld@pinc-software.de> |
At least temporary fix for the Deskbar not updating additional items (unless you resize it). The problem was that the view's screen clipping was not updated if its frame did not change because of a resized parent - but that might be needed if the new parent frame reveals a new portion of that view. I added a TODO so that if there is a way to test for this case, we only need to invalidate the clipping if really needed. For now, we always do it. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19695 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
|
#
46f579e7 |
|
06-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
removed intermediate variables, and added comments git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17033 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
61212865 |
|
01-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
More or less rewrote cursor conversion code: it's now working as expected. Note, this code needs to be reviewed for PPC; do they really work with little endian RGBA? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16960 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
|
#
9a0c4733 |
|
27-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* hopefully fixed the weird color inversion of colors with full saturation in the part where the cursor is transparent * fixed leakage of cursor data (placed making the copy it in the wrong bracket) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16523 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
588259b6 |
|
26-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
various changes to handling custom cursors: * all cursors owned by a team are visually different, or (iaw) an already existing cursor is reused when it is set by the client again * changed various occurances of cursor data from "int8*" to "uint8*" * ServerCursors also remember the R5 data from which they were created * the reference counting and destruction of ServerCursors changed: The cursor knows it is attached to a CursorManager and one can simply use ServerCursor::Acquire() and Release() and the reference counting and everything is being taken care of * destroying a ViewLayer will now correctly release a set ServerCursor * fixed a race condition when setting a cursor through BView::SetViewCursor(): If the client code looks like this: BCursor cursor(cursorData); someView->SetViewCursor(&cursor, false); there is a relatively high chance the BCursor destructor told the ServerApp thread to destroy the cursor before the ServerWindow thread got to "acquire" the cursor for use by the view layer. The very same problem is likely the reason that SetViewCursor works to unreliably on R5, even when the "sync" flag is set to "true" (although it should theoretically work in that case). all these fixes make WonderBrush work fine again with the new support of custom cursors.... coded by axeld and myself (the joys of pair programming :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16521 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
195e980e |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Cursors are now reference counted, so it shouldn't be possible anymore to delete them accidently :) * You should no longer call HWInterface::SetCursor(), but the new Desktop::SetCursor() if you need to change the cursor. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16238 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aa1f5437 |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some work on cursors: * Fixed a myriad of bugs all over the place, ranging from locking errors to deleting objects that don't belong to the one deleting them (hello HWInterface!) * Almost all ServerWindow cursor stuff was broken; I've replaced all commands to set a cursor with a single one AS_SET_CURSOR. * Renamed some cursor commands. * Changed the (broken) way ServerApp::fAppCursor was maintained - the application cursor is now NULL as long as possible. * Removed superfluous ServerCursor app signature stuff. * The BApplication will no longer duplicate the default/I-beam cursors, it will just reuse the default ones which now have fixed tokens. * As a result, changing the cursor is now working as expected, closing bug #102. * Rewrote Cursor.h, renamed private members to match our style guide. * Minor cleanup. What's still left to be done is reference counting the cursor objects to make them work right and reliable. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16237 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9afc50fd |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
cosmetical changes and some bug fixes along the way, added another constructor to take on bitmap data from somewhere else git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12383 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
|
#
83e36298a5b98c92794ada46f5ae2a2de6e2861e |
|
27-Dec-2010 |
Michael Lotz <mmlr@mlotz.ch> |
CID 2977: Use the array delete operator. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39970 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
|
#
19e179ca4ff838084b9abb0dd19932ac5fcd0051 |
|
19-Jun-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Moved the implementation of SetViewCursor from the thread of the window of the view into the application thread. This solves the race condition with asynchronous SetViewCursor and deleting the cursor immediately afterwards for real. * The ServerApp now requires a reference to the current cursor, just in case... * Added TODOs for caching the BView token, it's currently resolved for every single BView call that talks to the server... not good! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31133 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bbe2597fb6cb26270842f57b6cdf5c8bd4c82354 |
|
13-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
CID 18 and CID 19: Fix leaking the cursor data. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27487 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c6f9f65dff468f7f1a495f49b547f2833ace03dd |
|
03-Jan-2007 |
Axel Dörfler <axeld@pinc-software.de> |
At least temporary fix for the Deskbar not updating additional items (unless you resize it). The problem was that the view's screen clipping was not updated if its frame did not change because of a resized parent - but that might be needed if the new parent frame reveals a new portion of that view. I added a TODO so that if there is a way to test for this case, we only need to invalidate the clipping if really needed. For now, we always do it. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19695 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
|
#
46f579e7efa3935eb8e90d5cd1068173d3c51c36 |
|
06-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
removed intermediate variables, and added comments git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17033 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
61212865dc83ad3d0ac9db28eee7bd2f9048a15a |
|
01-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
More or less rewrote cursor conversion code: it's now working as expected. Note, this code needs to be reviewed for PPC; do they really work with little endian RGBA? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16960 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
|
#
9a0c473378be5e441bebdcbaa6096bde2c88f354 |
|
27-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* hopefully fixed the weird color inversion of colors with full saturation in the part where the cursor is transparent * fixed leakage of cursor data (placed making the copy it in the wrong bracket) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16523 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
588259b66d15a3bde1fae53833230bbe28a4e8b0 |
|
26-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
various changes to handling custom cursors: * all cursors owned by a team are visually different, or (iaw) an already existing cursor is reused when it is set by the client again * changed various occurances of cursor data from "int8*" to "uint8*" * ServerCursors also remember the R5 data from which they were created * the reference counting and destruction of ServerCursors changed: The cursor knows it is attached to a CursorManager and one can simply use ServerCursor::Acquire() and Release() and the reference counting and everything is being taken care of * destroying a ViewLayer will now correctly release a set ServerCursor * fixed a race condition when setting a cursor through BView::SetViewCursor(): If the client code looks like this: BCursor cursor(cursorData); someView->SetViewCursor(&cursor, false); there is a relatively high chance the BCursor destructor told the ServerApp thread to destroy the cursor before the ServerWindow thread got to "acquire" the cursor for use by the view layer. The very same problem is likely the reason that SetViewCursor works to unreliably on R5, even when the "sync" flag is set to "true" (although it should theoretically work in that case). all these fixes make WonderBrush work fine again with the new support of custom cursors.... coded by axeld and myself (the joys of pair programming :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16521 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
195e980ef10d42d13bf8f4360d81eebda3b8417e |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Cursors are now reference counted, so it shouldn't be possible anymore to delete them accidently :) * You should no longer call HWInterface::SetCursor(), but the new Desktop::SetCursor() if you need to change the cursor. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16238 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aa1f5437999ab8531f33139c129c6bcaceb74e7a |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some work on cursors: * Fixed a myriad of bugs all over the place, ranging from locking errors to deleting objects that don't belong to the one deleting them (hello HWInterface!) * Almost all ServerWindow cursor stuff was broken; I've replaced all commands to set a cursor with a single one AS_SET_CURSOR. * Renamed some cursor commands. * Changed the (broken) way ServerApp::fAppCursor was maintained - the application cursor is now NULL as long as possible. * Removed superfluous ServerCursor app signature stuff. * The BApplication will no longer duplicate the default/I-beam cursors, it will just reuse the default ones which now have fixed tokens. * As a result, changing the cursor is now working as expected, closing bug #102. * Rewrote Cursor.h, renamed private members to match our style guide. * Minor cleanup. What's still left to be done is reference counting the cursor objects to make them work right and reliable. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16237 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9afc50fd98362fe22cb4def167d9a19d2dfc39f6 |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
cosmetical changes and some bug fixes along the way, added another constructor to take on bitmap data from somewhere else git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12383 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
|