Searched +hist:8 +hist:c5a0acc (Results 1 - 2 of 2) sorted by relevance
| /haiku/src/kits/app/ | ||
| H A D | ServerMemoryAllocator.cpp | diff 8e2140fa Sun Apr 29 12:21:40 MDT 2012 Axel Dörfler <axeld@pinc-software.de> Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824. diff 8c5a0acc Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8c5a0acc Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8e2140fa5eb8a019a5134ce041499d14b7ced7a3 Sun Apr 29 12:21:40 MDT 2012 Axel Dörfler <axeld@pinc-software.de> Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824. diff 8c5a0accf5d61de8e2beb7d079d022c56ed0a3f2 Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
| /haiku/src/kits/interface/ | ||
| H A D | Bitmap.cpp | diff 8e2140fa Sun Apr 29 12:21:40 MDT 2012 Axel Dörfler <axeld@pinc-software.de> Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824. diff 8c5a0acc Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8c5a0acc Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 8e2140fa5eb8a019a5134ce041499d14b7ced7a3 Sun Apr 29 12:21:40 MDT 2012 Axel Dörfler <axeld@pinc-software.de> Fixed a large client side memory leak for app_server memory. * The areas allocated for BBitmaps were never deleted, even though the app_server deleted its part when the memory got freed. * This resulted in a constant memory increase if the application in question would operate on many changing large bitmaps, like photos. * Since the bitmaps are reference counted, we don't actually know when to delete the areas, so that the app_server now notifies the client whenever that is possible. * This might fix #6824. diff 8c5a0accf5d61de8e2beb7d079d022c56ed0a3f2 Fri Jun 24 11:04:50 MDT 2011 Axel Dörfler <axeld@pinc-software.de> * Do not reserve memory when the area is too large. This fixes #7740 where the reserved amount was simply too small, but also works around address space waste with many larger bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42298 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 80 milliseconds