#
f6c51a5d |
|
23-Aug-2021 |
X512 <danger_mail@list.ru> |
BBitmap: add ability to specify client-defined area Change-Id: Iae1550b3088b0f6c26b0b91d9acb7f7cbcc721d3 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4369 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com> Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
|
#
edd34171 |
|
07-Jan-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
BBitmap: Introduce ImportBits variants that take BSizes. The old versions used pixel-count dimensions, not pixel-span dimensions as the entire rest of the API does, which was probably a mistake in the first place. The new APIs using BSize always use pixel-span dimensions. The old versions will shortly be deprecated. Discovered while working on Xlibe. Change-Id: I604a5ac6e0588420ff0b667d9193d60ac27b92c6
|
#
bb187c91 |
|
15-Sep-2021 |
Jérôme Duval <jerome.duval@gmail.com> |
interface: add colorspaces support for RGB48 and RGBA64 these colorspaces are packed as RGB or RGBA, not BGR or BGRA. RGB48_BIG and RGBA64 only differ in the endianess of the channel the 2-byte value. this is a big difference with RGB24_BIG and RGBA32_BIG, in which case _BIG means the order is RGB (BGR) and not BGR (BGRA). BGR48, BGRA64 could indeed be added, if needed. I chose 0x11 and 0x12 arbitrarily, but given the order of channels 0x1011 and 0x1012 might make more sense. This would mean using another bit for "real" bigendian colorspaces. Only the color conversion to 32-bits is implemented. Tested with the RAWTranslator modified to output 16bpp with success. Found some references in enum AVPixelFormat in libavutil/pixfmt.h. Change-Id: I4b023dec85d01f1e63e1b053139e5bb5d263a0e0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4468 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
6211ae25 |
|
04-Aug-2021 |
John Scipione <jscipione@gmail.com> |
BBitmap: Remove BeOS tweak to fix Spirograph 1.5 This is a BeOS app compatibility fix. The comment in SetBits implementation said that B_RGB32 imports only 24 bits of the data, but that doesn't seem to be correct. Fixes #12931 Change-Id: I826a7e358ea379b8bf1550c899e82b623e5c21b4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4319 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
2f41383c |
|
24-Aug-2015 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap: Archive the data also if "deep" is not set Fixes #12326
|
#
487d015a |
|
30-Apr-2015 |
Adrien Destugues <pulkomandy@gmail.com> |
PVS43: two if with same condition in BBitmap::SetBits
|
#
8e2140fa |
|
29-Apr-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.
|
#
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
|
#
0e35d5d2 |
|
12-Dec-2011 |
John Scipione <jscipione@gmail.com> |
Change instances of wether in comments to whether. No functional change intended.
|
#
3f0171ff |
|
29-Sep-2011 |
Axel Dörfler <axeld@pinc-software.de> |
* Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42781 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8c5a0acc |
|
24-Jun-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
|
#
65341d51 |
|
18-Aug-2010 |
Oliver Tappe <zooey@hirschkaefer.de> |
Someone familiar with BBitmap, please review: * BBitmap could leak fWindow in operator=() * two copy constructors didn't initialize the members properly, which could cause crashes in _CleanUp() * minor cleanup Actually found this while staring at CID 254-257, which were false alarm, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0eed9183 |
|
20-Aug-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Rewrote screen configuration management: VirtualScreen doesn't have anything to do with the configurations now, instead, there is a separated ScreenConfigurations class that maintains all known screen_configurations per workspace (and the Workspace::Private class has two of them, one for the current modes, one for the stored modes). * Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those. * Getting and setting of anything else than the current screen is now supported. * This change also fixes that a temporarily set screen mode was not being restored on workspace switch. * Also, the Deskbar now seems to have the wrong location a lot, which is something that should be easily fixable therefore. I will look into this next. * Got rid of the unhandy screen_id structure server side, and in BPrivateScreen; we now just use an int32 - the next API break should definitely replace the screen_id with a simple typedef. * Some cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32541 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
|
#
40265acf |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Fix the build git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31758 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
|
#
18cd67c7 |
|
22-Jan-2009 |
Michael Lotz <mmlr@mlotz.ch> |
Add missing headers (malloc/free, string functions, memcpy, etc. undeclared). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28982 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d7513239 |
|
18-Oct-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* reintroduce member fOffscreen which got removed in r2917 * check if locking the offscreen window succeeds before calling delete on it * don't return offscreen windows in CountWindows and WindowAt (works now as on R5) fixes ticket 1522, 1591, 1946, 2318 and propably more While creating an BBitmap in BApplication the bitmaps window looper would be added to the applications gLooperList, thus calling Quit() on that window and later delete on a stale window pointer in BBitmaps dtor. The Lock() check would fix the problem, but tests on R5 have shown that BApplication hides the offscreen window in CountWindows() and WindowAt(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28236 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a02979bb |
|
18-Oct-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* cleanup git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28235 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56c05e04 |
|
22-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Actually only allow bytes per row > 0 or B_ANY_BYTES_PER_ROW. Still we don't actually handle other invalid bpr values like if the width doesn't really fit into the provided bytes per row for example. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27696 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e55f4dd2 |
|
22-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Remove check for a supplied bytesPerRow < 0. Negative values are valid and indicate that a default bytes per row for a certain color space and width should be used (B_ANY_BYTES_PER_ROW). Fixes CID 55. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27691 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f8a63d3a |
|
09-Sep-2008 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
non 32 bit offscreen bitmaps were never cleared to white, due to the way they currently work: when the offscreen window is created, the current content of the bitmap is copied to the back buffer, and since the clearing came later, it was never copied to it. This fixes the problem with FlattenPictureTest not working correctly for colorspace different than RGB(A)32. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27389 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
|
#
417889ce |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Handle clearing to white on the client. This also makes sure that bitmaps are cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK). * Check the allocation of the BWindow in BBitmap for view accepting bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24344 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2693621 |
|
30-Sep-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the client and the server. This should fix bug #1490, but I haven't tested it yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c5812d39 |
|
26-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* no longer reschedule after releasing the bits lock. * LockBits() now fails with B_BUSY in case the current buffer is NULL. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21513 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d56eb9cf |
|
26-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* LockBits() now returns B_OK for non-overlay bitmaps, as that makes much more sense. * Added TODO about the possible use of the state parameter (would be nice to be compatible with R5 here, of course). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21510 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fdd0f4ce |
|
13-Nov-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Made copy constructor and assign public and implemented them. * Added BBitmap(const BBitmap&, uint32 flags) constructor as found in Dano/Zeta. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19270 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
72122293 |
|
15-Jul-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
The BWindow destructor is called with the window locked, but we need to unlock to acquire the menu semaphore. Updated BBitmap to lock he window on quit too. This fixes last problem mentioned in bug 406 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18156 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
11235ae7 |
|
10-Jul-2006 |
Jérôme Duval <korli@users.berlios.de> |
"class" is added by BArchivable::Archive(), no need to duplicate git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18086 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
630e0d5f |
|
06-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Looks like there is an ancient bitmap archiving format that doesn't know about bytes per row or flags. This fixes bug #518. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17346 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c923ce2e |
|
02-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Minor cleanup, and thanks for the fix, Rudolf! :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17296 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b034a8a3 |
|
02-May-2006 |
Rudolf Cornelissen <rudolf.cornelissen@gmail.com> |
added relaying updated bytes_per_row to BBitmap's properties in case a bitmap was created in the graphics memory (ie: overlay bitmaps). Now not only a bitmap's size is updated, but also the bytes_per_row property itself. Axel, please review and correct as needed. Thanks. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17295 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
|
#
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
|
#
3a8e8e42 |
|
21-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* Archive() should have been broken, because it didn't add the class name. Also returns the actual error from the BMessage::AddData() if there was any. Please people, correct code like that if you spot this elsewhere and don't write such code anymore. * the BMessage constructor should be more robust. * the copy constructor takes the possibility into account that BitsLength() does not match. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17187 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
428dcd5b |
|
17-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Copy the correct number of bytes when making a BBitmap copy. Unfortunately, this still doesn't fix Cortex drawin bug. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17155 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b57f2b53 |
|
13-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* added handy BBitmap::Flags() method * added NOTE to BBitmap::LockBits(), has anybody some insight into this? Otherwise we need to write a test app to discover its secrets... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17120 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
|
#
0ce9ba6b |
|
15-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* BPrivate::ConvertBits() did not take the source or destination bits length into account when copying to the same color space (new code isn't that fast, but it works). * BBitmap::ImportBits() did not take the specified offset into account at all. This fixes bug #313. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16812 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e78c06d1 |
|
14-Mar-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Reverted change 16774 as stippi's wish. The offset should be ignored when drawing bitmaps, but it's obviously not, at least in some case. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16781 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
23467f07 |
|
13-Mar-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap's constructor offsets the passed BRect to B_ORIGIN in case it isn't already. This fixes bug 301. Offset the rect in ChannelSlider too just in case. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16774 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
404ccd1a |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Added extended ImportBits() to BBitmap to allow the use of BPoint offsets. Is this too much feature creep? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16595 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
|
#
b09e53fa |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Wrote a new color conversion engine. It's 2-5 times faster than the old one (depending on colorspaces) and about half in size. I've put it into ColorConversion.cpp and moved PaletteConverter there too, cleaning up Bitmap.cpp. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16580 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f19839c2 |
|
01-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some groundwork for overlay support. If someone wants to finish this, feel free to continue (it would be nice to be notified before, though, in case I get to it again in the next weeks). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b2f9d190 |
|
06-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
using alpha is actually correct git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16243 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ccee0bb5 |
|
21-Jan-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
renamed fToken to fAreaOffset and use it instead of fArea for the area offset. Less hacky. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16031 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3276412e |
|
21-Jan-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Resolved a TODO in BBitmap: now the bitmap area is cloned when needed: i.e. when Bits() or ImportBits() is called. Works fine, but I'd feel better if someone reviewed git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16014 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ec17c60f |
|
07-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added a TODO why our bitmap code is currently pretty inefficient. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15390 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e7a77b5b |
|
06-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
You also need to delete cloned areas - they are areas like any other (just their contents are shared)! Some cleanup. BBitmap::Cleanup() doesn't ask for a reply from the server anymore (why should it care, anyway?). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15380 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a77d2937 |
|
25-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Put a small TODO into the file: apparently, color_distance() does bad things for Qemu - the loop to initialize the system color map takes two seconds over here. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15149 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d28dc0ce |
|
10-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
This fixes the build for the libbe_test target - there is no stdint.h in BeOS (and it shouldn't matter a lot in this case, anyway). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14850 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3b27f09 |
|
10-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
check if the bitmap size can even be expressed in an int32, set init status to B_BAD_VALUE if not. This works arround a bug in WonderBrush... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14845 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
94b0f7f7 |
|
07-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14768 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
89bdf573 |
|
04-Nov-2005 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
assigned names to "some BLocker"s to aid debugging git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14702 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c1ea1051 |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
added alpha support for pixel types and stuff in order to support B_TRANSPARENT_MAGIC_CMAP8 in the system palette... might need review, maybe there is a smarter way. The 0xff entry in the palette has alpha = 0 now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2e6a5805 |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
MenuField layouts the menu bar better with respect to fDivider, it aligns better with other controls. fDivider in TextControl is an integer number now, small fix and small cleanup in Menu, Window::InitData takes an optional BBitmap token to construct an offscreen window, fixed PrivateScreen IndexForColor, View prevents being located at fractional coordinates as in R5, BBitmap unlocks its offscreen window since it is never Show()n and needs manual unlocking, fixed Slider offscreen window mode and improved triange thumb drawing, ScrollView would not crash when passing a NULL target just for kicks, the private MenuBar class now implements Draw to draw itself a little differently inside the BMenuField (dark right and bottom side) - though how it currently sets the clipping region prevents the text controls to draw in Playground, needs fixing git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13450 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dd10337f |
|
14-Jun-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed BAppServerLink to AppServerLink, BPortLink to PortLink, LinkMsgReader to LinkReceiver, LinkMsgSender to LinkSender, and put everything into the BPrivate namespace. Made AppServerLink a cheap object - it will use the applications receiver/sender and not create its own buffers. Fixed broken communication stuff here and there (mostly Font.cpp). Put the newly introduced set|get_system_colors() into the BPrivate namespace - please don't introduce private functions into the public namespace!!! Also fixed their broken communication use, as Darkwyrm obviously forgot about it again: the sequence Flush(); GetNextMessage() without error checking is purely wrong and can make the app hang and/or crash! :-) Other minor cleanup. The input_server used some test mode with the haiku build target which is probably wrong. Hopefully I did not forget anything this time. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13128 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
38b35d9c |
|
29-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap now uses the correct (private) BWindow constructor. Partially implemented that constructor. Fixed another typo in BView, verified and removed some TODOs git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12884 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e29cd74b |
|
28-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Now BBitmap creates a BWindow in case it can accept views. This avoids a crash in the 'DragMe' sample app. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12870 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b54a7c44 |
|
28-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Stolen Ingo's code and implemented bitmaps_support_space(). Now BBitmap::InitObject() uses that one instead of the private method. I was obviously wrong about bitmaps_support_space() and get_pixel_size_for(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12868 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85b22604 |
|
25-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added B_BITMAP_NO_SERVER_LINK to the BBitmap flags. It constructs a BBitmap without a server link, which consequently cannot be drawn by the app_server, but which is nevertheless very useful. It essentially does the same thing as RUN_WITHOUT_APP_SERVER. I also added a CleanUp() function and moved the cleanup code from InitObject() there. CleanUp() is now called in the destructor, which means that the app_server now knows when to free the server side bitmap. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12814 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a84dde4c |
|
23-Feb-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Implemeted some methods for BBitmaps which accepts views, got rid of "NOT_IMPLEMENTED". Fixed a warning in ListView.cpp git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11461 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0aa393f4 |
|
18-Jan-2005 |
haydentech <haydentech@nowhere.fake> |
Conform to much stricter template rules as required by gcc 3.4 and later git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10851 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64bc6cc5 |
|
29-Aug-2004 |
DarkWyrm <darkwyrm@gmail.com> |
Checkin for Michael Lotz - implementation of unarchiving constructor git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8721 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
044be4e2 |
|
28-Aug-2004 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Introduced a new build flag and macro RUN_WITHOUT_APP_SERVER, to allow several things to work without a running app server (the Storage Kit to begin with). git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8695 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3ceb31b9 |
|
30-Jul-2004 |
DarkWyrm <darkwyrm@gmail.com> |
Pahtz's changes from PortLink/BSession/PortMessage/PortQueue to BPortLink git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8519 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e3a2e771 |
|
18-Jun-2004 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Be nice and explain why we don't free fBasePtr. Implemented Area() git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8037 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
843f00a1 |
|
18-Jun-2004 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Removes a crash in the BApplication tests. Some tests work now. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8036 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
99991325 |
|
04-Oct-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Bugfixes. AFAIK everything works properly. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4945 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
55c8a39e |
|
03-Oct-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Conversion of PortLink::FlushWithReply calls from deprecated API calls git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4934 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
edd19f3d |
|
01-Sep-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Removed a few compiler warnings Added app-side support for font list Added mostly-empty global font functions and documented them git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4439 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
19de2978 |
|
11-Jul-2003 |
shadow303 <shadow303@nowhere.fake> |
Updates for changes in PortLink & PortMessage git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3958 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c0b3b847 |
|
11-Jul-2003 |
haydentech <haydentech@nowhere.fake> |
major warning reduction for gcc3, plus namespace and other gcc3 fixes git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3952 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e30edc58 |
|
12-Mar-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Doh! Forgot the Create_Bitmap attachments. I need my coffee... git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2897 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f4ccda5e |
|
12-Mar-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Added bitmap allocation code which talks to the app_server git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2896 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
435fb427 |
|
02-Sep-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Added documentation. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@967 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e0f91d2b |
|
01-Sep-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Added implementation of SetBits() and new ImportBits() API methods. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@952 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bffaf34a |
|
27-Aug-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Initial version of provisional BBitmap implementation. Save SetBits() all functions of current interest are implemented. A helper class for palatte <-> true color conversion is in place. Nothing is tested. Currently not included in the build. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@904 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2f41383c3bf2993545ffc687afbc82196a95f5e0 |
|
24-Aug-2015 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap: Archive the data also if "deep" is not set Fixes #12326
|
#
487d015ab7568556aa8bd703baf34f3896a6847d |
|
30-Apr-2015 |
Adrien Destugues <pulkomandy@gmail.com> |
PVS43: two if with same condition in BBitmap::SetBits
|
#
8e2140fa5eb8a019a5134ce041499d14b7ced7a3 |
|
29-Apr-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.
|
#
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
|
#
0e35d5d2e5ef3d288e056d60ef1b16dc399eaa0c |
|
12-Dec-2011 |
John Scipione <jscipione@gmail.com> |
Change instances of wether in comments to whether. No functional change intended.
|
#
3f0171fff5cfe71c9114a95eefdbd31a677e1113 |
|
29-Sep-2011 |
Axel Dörfler <axeld@pinc-software.de> |
* Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42781 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8c5a0accf5d61de8e2beb7d079d022c56ed0a3f2 |
|
24-Jun-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
|
#
65341d518fdcec10d88675dea8c04141daa9f738 |
|
18-Aug-2010 |
Oliver Tappe <zooey@hirschkaefer.de> |
Someone familiar with BBitmap, please review: * BBitmap could leak fWindow in operator=() * two copy constructors didn't initialize the members properly, which could cause crashes in _CleanUp() * minor cleanup Actually found this while staring at CID 254-257, which were false alarm, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38246 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0eed9183061a7763972bc2589f9c43489cd078ab |
|
20-Aug-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Rewrote screen configuration management: VirtualScreen doesn't have anything to do with the configurations now, instead, there is a separated ScreenConfigurations class that maintains all known screen_configurations per workspace (and the Workspace::Private class has two of them, one for the current modes, one for the stored modes). * Added Desktop::{Get|Set}ScreenMode() methods, ServerApp now only calls those. * Getting and setting of anything else than the current screen is now supported. * This change also fixes that a temporarily set screen mode was not being restored on workspace switch. * Also, the Deskbar now seems to have the wrong location a lot, which is something that should be easily fixable therefore. I will look into this next. * Got rid of the unhandy screen_id structure server side, and in BPrivateScreen; we now just use an int32 - the next API break should definitely replace the screen_id with a simple typedef. * Some cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32541 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
|
#
40265acfb3f2b71df5576b1229ffb139406c2f66 |
|
26-Jul-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Fix the build git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31758 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
|
#
18cd67c76072f825c4a7ba58414771d47fd1bfa2 |
|
22-Jan-2009 |
Michael Lotz <mmlr@mlotz.ch> |
Add missing headers (malloc/free, string functions, memcpy, etc. undeclared). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28982 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d751323939575160b39a145750ddde4eb6f02b39 |
|
18-Oct-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* reintroduce member fOffscreen which got removed in r2917 * check if locking the offscreen window succeeds before calling delete on it * don't return offscreen windows in CountWindows and WindowAt (works now as on R5) fixes ticket 1522, 1591, 1946, 2318 and propably more While creating an BBitmap in BApplication the bitmaps window looper would be added to the applications gLooperList, thus calling Quit() on that window and later delete on a stale window pointer in BBitmaps dtor. The Lock() check would fix the problem, but tests on R5 have shown that BApplication hides the offscreen window in CountWindows() and WindowAt(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28236 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a02979bb3f339a9dd1b1d7dae4b2e856a4f73b77 |
|
18-Oct-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* cleanup git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28235 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56c05e04afb204fe30e94e43c5575bed72df63a8 |
|
22-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Actually only allow bytes per row > 0 or B_ANY_BYTES_PER_ROW. Still we don't actually handle other invalid bpr values like if the width doesn't really fit into the provided bytes per row for example. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27696 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e55f4dd23c69aee2d52b904cf232c550d859c7cb |
|
22-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
Remove check for a supplied bytesPerRow < 0. Negative values are valid and indicate that a default bytes per row for a certain color space and width should be used (B_ANY_BYTES_PER_ROW). Fixes CID 55. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27691 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f8a63d3a0b80a9f051dff66ce7310c5226fb3dc1 |
|
09-Sep-2008 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
non 32 bit offscreen bitmaps were never cleared to white, due to the way they currently work: when the offscreen window is created, the current content of the bitmap is copied to the back buffer, and since the clearing came later, it was never copied to it. This fixes the problem with FlattenPictureTest not working correctly for colorspace different than RGB(A)32. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27389 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
|
#
417889ced83de5a38e8d9dccdee23af9a1e770ff |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Handle clearing to white on the client. This also makes sure that bitmaps are cleared which have no app_server link (B_BITMAP_NO_SERVER_LINK). * Check the allocation of the BWindow in BBitmap for view accepting bitmaps. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24344 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2693621b6e93462629d439effd550df7f64ac49 |
|
30-Sep-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the client and the server. This should fix bug #1490, but I haven't tested it yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c5812d39a5b410a00ae4f167e82b3cb977f1865e |
|
26-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* no longer reschedule after releasing the bits lock. * LockBits() now fails with B_BUSY in case the current buffer is NULL. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21513 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d56eb9cf5d84b844f473ec02f496f432cfc49a36 |
|
26-Jun-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* LockBits() now returns B_OK for non-overlay bitmaps, as that makes much more sense. * Added TODO about the possible use of the state parameter (would be nice to be compatible with R5 here, of course). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21510 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fdd0f4ce104ed1845da62e0854f9333940e93eb1 |
|
13-Nov-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Made copy constructor and assign public and implemented them. * Added BBitmap(const BBitmap&, uint32 flags) constructor as found in Dano/Zeta. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19270 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7212229343784d9b2e4bad3c1e55ddde89eb9852 |
|
15-Jul-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
The BWindow destructor is called with the window locked, but we need to unlock to acquire the menu semaphore. Updated BBitmap to lock he window on quit too. This fixes last problem mentioned in bug 406 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18156 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
11235ae729e3f91f1141068276715a82e0b0928a |
|
10-Jul-2006 |
Jérôme Duval <korli@users.berlios.de> |
"class" is added by BArchivable::Archive(), no need to duplicate git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18086 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
630e0d5f82c050c71cd66d7c0b8ddcd4624f3dd5 |
|
06-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Looks like there is an ancient bitmap archiving format that doesn't know about bytes per row or flags. This fixes bug #518. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17346 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c923ce2ed200a98aee0d7b12645d36c93e0edd13 |
|
02-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Minor cleanup, and thanks for the fix, Rudolf! :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17296 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b034a8a36cb8a141c484136cc33ef7a53c37f828 |
|
02-May-2006 |
Rudolf Cornelissen <rudolf.cornelissen@gmail.com> |
added relaying updated bytes_per_row to BBitmap's properties in case a bitmap was created in the graphics memory (ie: overlay bitmaps). Now not only a bitmap's size is updated, but also the bytes_per_row property itself. Axel, please review and correct as needed. Thanks. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17295 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
|
#
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
|
#
3a8e8e427b9bac9397774fcf0285aeff3603fd7c |
|
21-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* Archive() should have been broken, because it didn't add the class name. Also returns the actual error from the BMessage::AddData() if there was any. Please people, correct code like that if you spot this elsewhere and don't write such code anymore. * the BMessage constructor should be more robust. * the copy constructor takes the possibility into account that BitsLength() does not match. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17187 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
428dcd5b4805c74f08bec097e09b66c0d4b0beb7 |
|
17-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Copy the correct number of bytes when making a BBitmap copy. Unfortunately, this still doesn't fix Cortex drawin bug. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17155 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b57f2b537e5d18964fe340829366bba657fd6dbf |
|
13-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* added handy BBitmap::Flags() method * added NOTE to BBitmap::LockBits(), has anybody some insight into this? Otherwise we need to write a test app to discover its secrets... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17120 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
|
#
0ce9ba6ba32a6e28971899c78b83ae4c63b231fb |
|
15-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* BPrivate::ConvertBits() did not take the source or destination bits length into account when copying to the same color space (new code isn't that fast, but it works). * BBitmap::ImportBits() did not take the specified offset into account at all. This fixes bug #313. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16812 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e78c06d17082152772f849fa9f0425d9e6062af6 |
|
14-Mar-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Reverted change 16774 as stippi's wish. The offset should be ignored when drawing bitmaps, but it's obviously not, at least in some case. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16781 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
23467f07d91819696eae921de0fd3f566405f2f8 |
|
13-Mar-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap's constructor offsets the passed BRect to B_ORIGIN in case it isn't already. This fixes bug 301. Offset the rect in ChannelSlider too just in case. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16774 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
404ccd1a92b69b8b1c94382a1c7a2adae1ac57c4 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Added extended ImportBits() to BBitmap to allow the use of BPoint offsets. Is this too much feature creep? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16595 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
|
#
b09e53fae0c50ed31994c3f03d477ae2af8ab951 |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Wrote a new color conversion engine. It's 2-5 times faster than the old one (depending on colorspaces) and about half in size. I've put it into ColorConversion.cpp and moved PaletteConverter there too, cleaning up Bitmap.cpp. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16580 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f19839c230e64120d4b9e9fda83d1578445d232f |
|
01-Mar-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some groundwork for overlay support. If someone wants to finish this, feel free to continue (it would be nice to be notified before, though, in case I get to it again in the next weeks). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b2f9d1906b3051cfa99b9927b1b7cf7a5316b957 |
|
06-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
using alpha is actually correct git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16243 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ccee0bb56dcf520a685a1925fea81471a6f8dafc |
|
21-Jan-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
renamed fToken to fAreaOffset and use it instead of fArea for the area offset. Less hacky. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16031 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3276412ef2f4ff222ccb5fd579ce3505e84a785c |
|
21-Jan-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Resolved a TODO in BBitmap: now the bitmap area is cloned when needed: i.e. when Bits() or ImportBits() is called. Works fine, but I'd feel better if someone reviewed git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16014 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ec17c60f5af36e4075cbe926b8ed8ddf8a42306f |
|
07-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added a TODO why our bitmap code is currently pretty inefficient. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15390 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e7a77b5b71e6aeef85d5c6fe91e67e2d5404aa4d |
|
06-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
You also need to delete cloned areas - they are areas like any other (just their contents are shared)! Some cleanup. BBitmap::Cleanup() doesn't ask for a reply from the server anymore (why should it care, anyway?). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15380 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a77d29375c486628da819b1bdb5fdc5ba9bb6aee |
|
25-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Put a small TODO into the file: apparently, color_distance() does bad things for Qemu - the loop to initialize the system color map takes two seconds over here. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15149 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d28dc0ce83e2ea96cc35ce8e5c1af7241c63629b |
|
10-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
This fixes the build for the libbe_test target - there is no stdint.h in BeOS (and it shouldn't matter a lot in this case, anyway). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14850 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3b27f09af58c0d870c824bf262744d6aed2eb76 |
|
10-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
check if the bitmap size can even be expressed in an int32, set init status to B_BAD_VALUE if not. This works arround a bug in WonderBrush... :-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14845 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
94b0f7f71c58d439dffd7fabe6cab0958f620c53 |
|
07-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14768 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
89bdf57382fda0be1f959d118e044b85b0775303 |
|
04-Nov-2005 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
assigned names to "some BLocker"s to aid debugging git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14702 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c1ea105142e54948c86c03d756aa9dbd3fa7e0b6 |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
added alpha support for pixel types and stuff in order to support B_TRANSPARENT_MAGIC_CMAP8 in the system palette... might need review, maybe there is a smarter way. The 0xff entry in the palette has alpha = 0 now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13472 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2e6a5805ba8db3b072d81257cc44f966def5fd37 |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
MenuField layouts the menu bar better with respect to fDivider, it aligns better with other controls. fDivider in TextControl is an integer number now, small fix and small cleanup in Menu, Window::InitData takes an optional BBitmap token to construct an offscreen window, fixed PrivateScreen IndexForColor, View prevents being located at fractional coordinates as in R5, BBitmap unlocks its offscreen window since it is never Show()n and needs manual unlocking, fixed Slider offscreen window mode and improved triange thumb drawing, ScrollView would not crash when passing a NULL target just for kicks, the private MenuBar class now implements Draw to draw itself a little differently inside the BMenuField (dark right and bottom side) - though how it currently sets the clipping region prevents the text controls to draw in Playground, needs fixing git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13450 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dd10337fd005a67a4947714fdeecf2121485b91d |
|
14-Jun-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed BAppServerLink to AppServerLink, BPortLink to PortLink, LinkMsgReader to LinkReceiver, LinkMsgSender to LinkSender, and put everything into the BPrivate namespace. Made AppServerLink a cheap object - it will use the applications receiver/sender and not create its own buffers. Fixed broken communication stuff here and there (mostly Font.cpp). Put the newly introduced set|get_system_colors() into the BPrivate namespace - please don't introduce private functions into the public namespace!!! Also fixed their broken communication use, as Darkwyrm obviously forgot about it again: the sequence Flush(); GetNextMessage() without error checking is purely wrong and can make the app hang and/or crash! :-) Other minor cleanup. The input_server used some test mode with the haiku build target which is probably wrong. Hopefully I did not forget anything this time. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13128 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
38b35d9caa2505146411842de6734e0a3b5031df |
|
29-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
BBitmap now uses the correct (private) BWindow constructor. Partially implemented that constructor. Fixed another typo in BView, verified and removed some TODOs git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12884 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e29cd74b0dfb7f67a088d69f34741eca2e1e9e8c |
|
28-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Now BBitmap creates a BWindow in case it can accept views. This avoids a crash in the 'DragMe' sample app. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12870 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b54a7c449ebf973db8a3f457d014827df6d2001f |
|
28-May-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Stolen Ingo's code and implemented bitmaps_support_space(). Now BBitmap::InitObject() uses that one instead of the private method. I was obviously wrong about bitmaps_support_space() and get_pixel_size_for(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12868 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85b226041acb76fa52d823f0a68074d9a7df8687 |
|
25-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added B_BITMAP_NO_SERVER_LINK to the BBitmap flags. It constructs a BBitmap without a server link, which consequently cannot be drawn by the app_server, but which is nevertheless very useful. It essentially does the same thing as RUN_WITHOUT_APP_SERVER. I also added a CleanUp() function and moved the cleanup code from InitObject() there. CleanUp() is now called in the destructor, which means that the app_server now knows when to free the server side bitmap. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12814 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a84dde4cdea85f6601bf3f5548f29787d534df33 |
|
23-Feb-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Implemeted some methods for BBitmaps which accepts views, got rid of "NOT_IMPLEMENTED". Fixed a warning in ListView.cpp git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11461 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0aa393f4113dbd4404e7766b25957818a17db635 |
|
18-Jan-2005 |
haydentech <haydentech@nowhere.fake> |
Conform to much stricter template rules as required by gcc 3.4 and later git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10851 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64bc6cc549f1816aec9791f64bdc04c2ab27723b |
|
29-Aug-2004 |
DarkWyrm <darkwyrm@gmail.com> |
Checkin for Michael Lotz - implementation of unarchiving constructor git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8721 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
044be4e25857fbf35770973fa5785c0a165d4188 |
|
28-Aug-2004 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Introduced a new build flag and macro RUN_WITHOUT_APP_SERVER, to allow several things to work without a running app server (the Storage Kit to begin with). git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8695 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3ceb31b96aefa3601ccc51e415da557b00155d4f |
|
30-Jul-2004 |
DarkWyrm <darkwyrm@gmail.com> |
Pahtz's changes from PortLink/BSession/PortMessage/PortQueue to BPortLink git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8519 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e3a2e77198bcfa3d23a6285a4a9cc63b69f32080 |
|
18-Jun-2004 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Be nice and explain why we don't free fBasePtr. Implemented Area() git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8037 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
843f00a15ed5921854c2dba8aa56d55467edef06 |
|
18-Jun-2004 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Removes a crash in the BApplication tests. Some tests work now. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8036 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
99991325e3e87499f1024259ea66b3ed3496bc82 |
|
04-Oct-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Bugfixes. AFAIK everything works properly. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4945 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
55c8a39e564d4a7e6bfca68f576a773747046b0e |
|
03-Oct-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Conversion of PortLink::FlushWithReply calls from deprecated API calls git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4934 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
edd19f3d5c870bf9cc72f9d9d89de4c002d7a580 |
|
01-Sep-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Removed a few compiler warnings Added app-side support for font list Added mostly-empty global font functions and documented them git-svn-id: file:///srv/svn/repos/haiku/trunk/current@4439 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
19de29789adf647cfc61394318dbd4c74e59dbc7 |
|
11-Jul-2003 |
shadow303 <shadow303@nowhere.fake> |
Updates for changes in PortLink & PortMessage git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3958 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c0b3b8475fe4427a968cbcc99096a14cce6e05bc |
|
11-Jul-2003 |
haydentech <haydentech@nowhere.fake> |
major warning reduction for gcc3, plus namespace and other gcc3 fixes git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3952 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e30edc58265ec769e3eee225ee49ea44829c63a3 |
|
12-Mar-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Doh! Forgot the Create_Bitmap attachments. I need my coffee... git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2897 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f4ccda5e464e551e4159199fba46af70dad06cb9 |
|
12-Mar-2003 |
DarkWyrm <darkwyrm@gmail.com> |
Added bitmap allocation code which talks to the app_server git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2896 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
435fb4275c1e4eb4d99a819f4aae33db37d50348 |
|
02-Sep-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Added documentation. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@967 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e0f91d2b8c86fb566df514f2d38144559c2e3461 |
|
01-Sep-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Added implementation of SetBits() and new ImportBits() API methods. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@952 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bffaf34afeccafbec088207453a926bbb4b2611f |
|
27-Aug-2002 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Initial version of provisional BBitmap implementation. Save SetBits() all functions of current interest are implemented. A helper class for palatte <-> true color conversion is in place. Nothing is tested. Currently not included in the build. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@904 a95241bf-73f2-0310-859d-f6bbb57e9c96
|