Commit Graph

15 Commits

Author SHA1 Message Date
Stephan Aßmus
39c9925fcf * implemented a BRegion pool per WindowLayer which is supposed
to cut down on BRegion related allocations, cannot really tell
  if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
  a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
  the debugger if you
    - try to nest read locks
    - try to write lock when your are a reader already
    - don't match up nested locks when your a writer
    -> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
  and fixed the locking for use with the MultiLocker, the "a reader can
  not become a writer" is especially tricky, feel free to review the
  changes
* activated the MultiLocker, I tested this quite a bit, if there are
  problems simply turn on DEBUG and you should drop into the debugger
  right where the problem is... hope all is good


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-04-07 19:14:25 +00:00
Axel Dörfler
9a44fdc97c * 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 13:43:26 +00:00
Michael Lotz
0581480cfe * Fixed ServerBitmap::ImportBits() to use the correct width/height
* Extended ConvertBits() to properly handle negative offsets and overlapping lines
* Implemented blitting the software cursor to the bitmap returned from ReadBitmap()

Note: In the future we will have to directly use the final graphics buffer for ReadBitmap() if we want DirectWindow output too (R5 includes it). I don't know how R5 handles the hardware cursor though.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16766 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-13 16:48:44 +00:00
Michael Lotz
ee18c3ccff Added an extended ImportBits() to ServerBitmap to allow the use of offsets and made ReadBitmap() use it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16593 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-06 00:18:26 +00:00
Michael Lotz
bdc6f9e7ef * Fixed a swapping bug for 16 bit colorspaces
* Added some comments
* Added some checking to avoid noop shifts
* Added buffer length checks
* Implemented (as Stephan suggested) a version of ConvertBits() that takes offsets.
This new version allows to move a region of the source into a region (possibly not at the same point) on the dest while converting colorspaces on the fly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16592 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-05 23:53:33 +00:00
Michael Lotz
acfad7920c Added an ImportBits() function to ServerBitmap and used it in ReadBitmap(). Should work for all colorspaces now.
Magnify does now work correctly, fixed bug 197.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16581 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-03-05 12:59:39 +00:00
Axel Dörfler
aa1f543799 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
2006-02-05 18:14:14 +00:00
Axel Dörfler
4acb99b60f 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
2005-12-29 15:36:18 +00:00
Ingo Weinhold
758b1d0e05 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
2005-11-12 23:27:14 +00:00
Stephan Aßmus
75d26e104a fInitialized is also set in the copy constructor. BTW, the Haiku Logo is displayed now (forgot to commit this earlier). Thanks to Axel for finding out about this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13110 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-06-14 00:38:21 +00:00
Axel Dörfler
6262418e6a fInitialized was never set to "true", so InitCheck() could never succeed.
Also fixed _AllocateBuffer() to handle out of memory situations gracefully.
It should probably also have upper limits with regard to the bitmap size.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13109 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-06-14 00:12:45 +00:00
Stefano Ceccherini
f39e1df2de delete -> delete[]
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12918 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-06-01 08:55:39 +00:00
Stephan Aßmus
1e1b1675de really implement BitsLength() inline, I have no idea why it compiled for me...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12418 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-04-15 15:31:57 +00:00
Stephan Aßmus
ec668ad701 Cosmetical changes and quite a few bug fixes along the way - B_RGB24 is definitely not supposed to be 32 bits per pixel. For example. Added another constructor to take on bitmap data from somewhere else
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12384 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-04-14 00:06:01 +00:00
Axel Dörfler
33bbe22391 Moved app_server files to app/.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11972 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-03-24 14:45:52 +00:00