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>

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

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>

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>

BBitmap: Archive the data also if "deep" is not set
Fixes #12326

PVS43: two if with same condition in BBitmap::SetBits

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.

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

Change instances of wether in comments to whether. No functional change intended.

* Minor cleanup.


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

* 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

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

* 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

* Some style cleanups, no functional change.


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

Fix the build


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

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

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

* 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

* cleanup



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

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

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

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

* 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

* 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

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

* 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

* 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

* 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

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

"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

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

Minor cleanup, and thanks for the fix, Rudolf! :-)


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

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

* 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

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

* 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

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

* 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

* 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

* 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

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

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

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

* 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

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

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

using alpha is actually correct

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

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

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

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

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

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

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

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

Minor cleanup.


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

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

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

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

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

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

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

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

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

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

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

Checkin for Michael Lotz - implementation of unarchiving constructor


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

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

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

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

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

Bugfixes. AFAIK everything works properly.


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

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

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

Updates for changes in PortLink & PortMessage


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

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

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

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

Added documentation.


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

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

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

BBitmap: Archive the data also if "deep" is not set
Fixes #12326

PVS43: two if with same condition in BBitmap::SetBits

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.

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

Change instances of wether in comments to whether. No functional change intended.

* Minor cleanup.


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

* 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

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

* 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

* Some style cleanups, no functional change.


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

Fix the build


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

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

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

* 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

* cleanup



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

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

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

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

* 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

* 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

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

* 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

* 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

* 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

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

"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

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

Minor cleanup, and thanks for the fix, Rudolf! :-)


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

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

* 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

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

* 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

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

* 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

* 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

* 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

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

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

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

* 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

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

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

using alpha is actually correct

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

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

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

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

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

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

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

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

Minor cleanup.


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

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

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

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

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

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

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

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

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

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

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

Checkin for Michael Lotz - implementation of unarchiving constructor


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

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

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

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

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

Bugfixes. AFAIK everything works properly.


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

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

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

Updates for changes in PortLink & PortMessage


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

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

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

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

Added documentation.


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

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

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