#
3fed1a15 |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
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
|
#
87e7b978 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed race conditions in the server's bitmap/picture handling: the objects are now removed from the maps as soon as the client deletes them. This also makes the "client reference" mechanism superfluous I introduced earlier. * ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it is also called whenever the current application changes. This fixes the cursor almost never changing. * Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture(). * Also, they now acquire a reference to the picture in question (ie. the picture you get from PopPicture() also owns a reference you need to free). * ServerApp::CreatePicture() may fail, too. This case is now handled in the code that calls it. * Previously, the ServerWindow tried to process up to 70 messages in one go. That obviously caused bug #4709. Now, we have the additional requirement to not hold the desktop lock for longer than 25 ms. I haven't tested it with Kaleidoscope yet, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
afad65b2 |
|
19-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Bitmaps and pictures now maintain their client reference independently; clients can no longer release more references than they own. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 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
|
#
63c07622 |
|
26-Jul-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Some style cleanups, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31759 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab53bb20 |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Export get_bytes_per_row() from InterfacePrivate.h, and use it in ServerBitmap in place of the own rolled implementation. Comment typo fix. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ba823bcb |
|
24-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
fBuffer was allocated with new and freed with "free()". Fixedx git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31738 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e6a52fe4 |
|
22-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Setting the font family/style in a BPicture works now. Added a comment to ServerBitmap git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31691 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
de6a19ee |
|
21-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Got rid of fBitsPerPixel (and BitsPerPixel()) in ServerBitmap, since they were nowhere used. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31677 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
42ed4fd7 |
|
28-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Rearranged includes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26664 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
|
#
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
|
#
9781d591 |
|
11-Mar-2007 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Include <util/kernel_cpp.h> in DoublyLinkedList.h only when compiling for the kernel. Added missing includes in userland code that uses the header. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20366 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
|
#
f7c7883b |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 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
|
#
39c9925f |
|
07-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
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
|
#
0581480c |
|
13-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* 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
|
#
ee18c3cc |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
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
|
#
bdc6f9e7 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* 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
|
#
acfad792 |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
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
|
#
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
|
#
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
|
#
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
|
#
75d26e10 |
|
13-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
6262418e |
|
13-Jun-2005 |
Axel Dörfler <axeld@pinc-software.de> |
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
|
#
f39e1df2 |
|
01-Jun-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
delete -> delete[] git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12918 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
1e1b1675 |
|
15-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
ec668ad7 |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
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
|
#
3fed1a15f58e8d6fe6b492f3b94bb3625ffeddbd |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
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
|
#
87e7b978aacfb3de11892ccd71894acf675ab0b8 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed race conditions in the server's bitmap/picture handling: the objects are now removed from the maps as soon as the client deletes them. This also makes the "client reference" mechanism superfluous I introduced earlier. * ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it is also called whenever the current application changes. This fixes the cursor almost never changing. * Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture(). * Also, they now acquire a reference to the picture in question (ie. the picture you get from PopPicture() also owns a reference you need to free). * ServerApp::CreatePicture() may fail, too. This case is now handled in the code that calls it. * Previously, the ServerWindow tried to process up to 70 messages in one go. That obviously caused bug #4709. Now, we have the additional requirement to not hold the desktop lock for longer than 25 ms. I haven't tested it with Kaleidoscope yet, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
afad65b245eb0c70300cbef4929db0ff8ccbec00 |
|
19-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Bitmaps and pictures now maintain their client reference independently; clients can no longer release more references than they own. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 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
|
#
63c07622f6bab3690e8c413fb11d62ca2c746670 |
|
26-Jul-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Some style cleanups, no functional change. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31759 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ab53bb20860dbd591ac92f20ea9288941610302a |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Export get_bytes_per_row() from InterfacePrivate.h, and use it in ServerBitmap in place of the own rolled implementation. Comment typo fix. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ba823bcb171563c48be1d799f372bd5cda07968a |
|
24-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
fBuffer was allocated with new and freed with "free()". Fixedx git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31738 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e6a52fe4b72bcfc86c9ff7f205ea6a76cf7c6c3b |
|
22-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Setting the font family/style in a BPicture works now. Added a comment to ServerBitmap git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31691 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
de6a19ee14b11c191b043a7274f6380022155f19 |
|
21-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Got rid of fBitsPerPixel (and BitsPerPixel()) in ServerBitmap, since they were nowhere used. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31677 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
42ed4fd712b5752323e4f7879cc38827060e7c0f |
|
28-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Rearranged includes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26664 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
|
#
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
|
#
9781d591cb022992380e8a98db7639f91f9bb93c |
|
11-Mar-2007 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Include <util/kernel_cpp.h> in DoublyLinkedList.h only when compiling for the kernel. Added missing includes in userland code that uses the header. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20366 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
|
#
f7c7883b9f7be15d6ffcc066e0f75e3d878c7923 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 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
|
#
39c9925fcf718dbb8c8d5342997d6bbd40f9e7e4 |
|
07-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
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
|
#
0581480cfec831197846c0449f838768412e2e03 |
|
13-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* 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
|
#
ee18c3ccff16d9fbd767dca092b4953f9a922785 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
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
|
#
bdc6f9e7ef0a4ef9c8f729c2979af0c0207fd007 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* 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
|
#
acfad7920cd256d36fc7848c8b1da5d83cc3363c |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
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
|
#
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
|
#
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
|
#
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
|
#
75d26e104abe3f0e677dd83c34141806c842e039 |
|
13-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
6262418e6a1d929934bf4c9828c0b6e489286fa8 |
|
13-Jun-2005 |
Axel Dörfler <axeld@pinc-software.de> |
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
|
#
f39e1df2de22df524795f01a366ef994ac8429c4 |
|
01-Jun-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
delete -> delete[] git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12918 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
1e1b1675de2597cb0334e4abeed06b423460cab5 |
|
15-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
ec668ad701c2434d00c18d3afa5e0900ef19714c |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
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
|