Searched +hist:8 +hist:e2140fa (Results 1 - 7 of 7) sorted by relevance

/haiku/src/kits/app/
H A DServerMemoryAllocator.cppdiff 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 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 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
H A DApplication.cppdiff 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 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 8eae8b05 Wed Jun 08 01:36:41 MDT 2005 Stefano Ceccherini <stefano.ceccherini@gmail.com> Every BApplication (even applications which didn't use it) allocated a BPrivateScreen object. Now they are created/destroyed on demand (when a BScreen object is constructed), and reference counted, so that there is still only one per app. Note that since we are creating/deleting them, constructing a BScreen object can be more time consuming than before, but personally I find this approach much cleaner.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13006 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8a526591 Sun Jul 28 13:33:00 MDT 2002 Ingo Weinhold <ingo_weinhold@gmx.de> * Moved some reusable code into AppMisc.cpp/h.
* Init be_app in InitData().
* Uninit be_app and be_app_messenger in BApplication destructor.^


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@513 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 8eae8b05e84b91859ad701bde81aa3596d8c693e Wed Jun 08 01:36:41 MDT 2005 Stefano Ceccherini <stefano.ceccherini@gmail.com> Every BApplication (even applications which didn't use it) allocated a BPrivateScreen object. Now they are created/destroyed on demand (when a BScreen object is constructed), and reference counted, so that there is still only one per app. Note that since we are creating/deleting them, constructing a BScreen object can be more time consuming than before, but personally I find this approach much cleaner.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13006 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8a526591a0c7147ba02ae272be83fbf36ceabd30 Sun Jul 28 13:33:00 MDT 2002 Ingo Weinhold <ingo_weinhold@gmx.de> * Moved some reusable code into AppMisc.cpp/h.
* Init be_app in InitData().
* Uninit be_app and be_app_messenger in BApplication destructor.^


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@513 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/servers/app/
H A DClientMemoryAllocator.cppdiff 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 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 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.
H A DServerApp.hdiff 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 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 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.
H A DServerApp.cppdiff 8b2b3010 Sat Jul 18 11:55:06 MDT 2020 Adrien Destugues <adrien.destugues@opensource.viveris.fr> app_server: save/restore screen brightness settings

The brightness is saved in the screen configurations of the first
workspace. For now, all screens get the same brightness (I can't get
screen IDs to work today). Since we only support setting the brightness
for laptop displays for now, this shouldn't matter. It can be fixed when
app_server gets actual multiple display support.

Fixes #14254

Change-Id: Ib33aa65a73407a65bd469d0efa8542210fec02d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/362
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
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 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 8b56f14a Fri Mar 12 04:07:23 MST 2010 Stephan Aßmus <superstippi@gmx.de> Fixed debug build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8bca36b1 Thu Aug 27 03:27:03 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Fixed locking order reversion as spotted by Stefano.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32744 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8a2dad71 Fri Apr 18 17:19:31 MDT 2008 Karsten Heimrich <host.haiku@gmx.de> * no need to reply, as set_ui_color won't read it anyway
Fixes some strage behavior (moving/disappearing text) in
Appearance preflet while moving a color control chooser.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25035 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff a4de7fa0 Wed Feb 27 17:22:48 MST 2008 Axel Dörfler <axeld@pinc-software.de> * Do not trust the client! ServerFont::GetEscapements() now takes a
parameter for the length of the arrays, so that even if the char/byte
counts do not match, no memory is overwritten anymore.
This fixes bug #1862; .canna obviously contains invalid UTF-8
characters, or there is a bug in StyledEdit (or deeper) and it doesn't
call BFont::GetEscapements() correctly.
* Fixed some cases of unchecked allocations in the font handling methods
of ServerApp, added TODOs to all other ones.
* Improved error code when creating a window fails.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24160 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8d8f5950 Thu Nov 17 17:26:20 MST 2005 Axel Dörfler <axeld@pinc-software.de> Some cleanup, mostly GetHWInterface() to HWInterface().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15016 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 8b56f14aeba18bc3cea7e8f12708c7b155b374fa Fri Mar 12 04:07:23 MST 2010 Stephan Aßmus <superstippi@gmx.de> Fixed debug build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/kits/interface/
H A DBitmap.cppdiff 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 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 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/headers/private/app/
H A DServerProtocol.hdiff 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 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 2c69b5b6 Wed Aug 19 08:17:13 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Made the libbe_test environment basically working under Haiku - to actually
make it work, one would need to use versioning for all libbe symbols. This is
worth an 8k price per file that links against libbe.so, so I didn't want to
commit this as is. An alternative to this solution would be to write a
separate application that is responsible for the app_server's window. Comments
welcome.
* Removed BeOS compatbility of the libbe_test stuff.
* Renamed the libbe_test targets from *haiku* to *test*, ie. libbe_haiku.so is
now called libbe_test.so, haiku_registrar is now test_registrar, etc.
* This also removes BeOS compatibility from tracker/FSUtils.cpp (all BeOS
compatibility should be removed, but I don't want to make Alexandre more work
in his branch, and it's not urgent at all).
* Replaced the former "run" scripts for the test environment with a single
run script (see updated NOTES file).
* Removed the libbe_test target from some applications - this was only to help
developing them under BeOS, and is thus no longer necessary.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32521 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8f3f25cf Tue Jan 03 17:15:58 MST 2006 Stefano Ceccherini <stefano.ceccherini@gmail.com> Merged the four AS_LAYER_DRAW_BITMAP handlers into just one handler

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15842 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 2c69b5b6c0e7b481a0c43366a1942a6055cbb864 Wed Aug 19 08:17:13 MDT 2009 Axel Dörfler <axeld@pinc-software.de> * Made the libbe_test environment basically working under Haiku - to actually
make it work, one would need to use versioning for all libbe symbols. This is
worth an 8k price per file that links against libbe.so, so I didn't want to
commit this as is. An alternative to this solution would be to write a
separate application that is responsible for the app_server's window. Comments
welcome.
* Removed BeOS compatbility of the libbe_test stuff.
* Renamed the libbe_test targets from *haiku* to *test*, ie. libbe_haiku.so is
now called libbe_test.so, haiku_registrar is now test_registrar, etc.
* This also removes BeOS compatibility from tracker/FSUtils.cpp (all BeOS
compatibility should be removed, but I don't want to make Alexandre more work
in his branch, and it's not urgent at all).
* Replaced the former "run" scripts for the test environment with a single
run script (see updated NOTES file).
* Removed the libbe_test target from some applications - this was only to help
developing them under BeOS, and is thus no longer necessary.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32521 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8f3f25cf639fbce2117e53f2bdcab62c2c4b4e5c Tue Jan 03 17:15:58 MST 2006 Stefano Ceccherini <stefano.ceccherini@gmail.com> Merged the four AS_LAYER_DRAW_BITMAP handlers into just one handler

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

Completed in 402 milliseconds