History log of /haiku/src/kits/interface/GraphicsDefs.cpp
Revision Date Author Comments
# 9931e8ee 09-Feb-2024 nep <nep-git@packageloss.eu>

rgb_color: Add new APIs: Contrast(), IsLight(), IsDark()

- Remove perceptual_brightness
- Change implementation of rgb_color::Brightness() to the previous BPrivate::perceptual_brightness()
- Introduce convenience methods Contrast(rgb_color), IsLight() and IsDark()

Change-Id: Id677d4a32ce43d73bffecf9baf8cffaafb01a16d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7399
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# 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>


# 7f9368ca 09-Dec-2015 looncraz <looncraz@looncraz.net>

Set*UIColor, etc.

The inseparable changes necessary to support live color updating across the
system in a sane, safe, and performant manner.

BView gains:

HasSystemColors()
HasDefaultColors()
AdoptSystemColors()
AdoptParentColors()
AdoptViewColor(BView*)
SetViewUIColor(color_which, float tint)
SetHighUIColor(...
SetLowUIColor(...
ViewUIColor(float* tint)
HighUIColor(...
LowUIColor(...
DelayedInvalidate()

BWindow gains a simple helper method:
IsOffscreenWindow()

BMessage gains:

AddColor()
FindColor()
GetColor()
HasColor() * allegedly this API is deprecated, but I implemented it anyway
ReplaceColor()
SetColor()

Previous private ColorTools methods are made public and moved into GraphicsDefs:

mix_color, blend_color, disable_color

These are fully compatible with BeOS dan0 R5.1 methods and are just code cleanup
of BeOS example code under the OpenTracker license.

In addition, four new colors are created:
B_LINK_TEXT_COLOR
B_LINK_HOVER_COLOR
B_LINK_ACTIVE_COLOR
B_LINK_VISITED_COLOR

These changes are documented in their proper user documentation files.

In addition, due to a history rewrite, B_FOLLOW_LEFT_TOP has been defined and
used in lieu of B_FOLLOW_TOP | B_FOLLOW_LEFT and is included in this commit.

On the app_server side, the following has changed:

Add DelayedMessage - a system by which messages can be sent at a scheduled time,
and can also be merged according to set rules. A single thread is used to service the
message queue and multiple recipients can be set for each message.
Desktop gains the ability to add message ports to a DelayedMessage so that
said messages can target either all applications or all windows, as needed.

Desktop maintains a BMessage which is used to queue up all pending color changes
and the delayed messaging system is used to enact these changes after a short
period of time has passed. This prevents abuse and allows the system to merge
repeated set_ui_color events into one event for client applications, improving
performance drastically.

In addition, B_COLORS_UPDATED is sent to the BApplication, which forwards the message
to each BWindow. This is done to improve performance over having the app_server
independently informing each window.

Decorator changes are live now, which required some reworking.

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>


# 636427b6 07-Jun-2008 Stephan Aßmus <superstippi@gmx.de>

Axel!! Since _Thursday_ I am trying to track this down. "MediaPlayer wouldn't
play any more clips." Of course I was searching in my own commits. In the
end, I resorted to binary searching revisions for when this broke. Turns out
it is your change r25793/r25794, in which you forgot to attach the colorspace
to the app_server message. Which of course makes it lock up. Another of those
instances where you think passing data structures between client and app_server
instead of this "protocol" would be the better idea...

* Fixed bitmaps_support_space() retrieving the currently supported overlay
flags for a given color space. This makes MediaPlayer play files again, the
media node connection would time out because of the broken app_server
communication. (I have not tested this change yet, but I will in a minute, on
a different computer.)
* Also retrieve the overlay supported flag for YCbCr colorspaces.


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


# 6ec21b4a 03-Jun-2008 Axel Dörfler <axeld@pinc-software.de>

* Implemented retrieving additional bitmap support flags by the app_server.
* Added B_BITMAPS_SUPPORT_OVERLAY flag to indicate overlay support for the
color space.
* Rewrote GraphicsDefs.h - the previous one was obvious a copy of the Be header,
including typos and strange white space. I was a bit lazy with respect to
the color space details, and mostly trusted the information provided by the
Be header else.


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


# 3dd59121 02-Jun-2008 Stephan Aßmus <superstippi@gmx.de>

Resolved TODO and set the flags for the kind of additional
bitmap support (bitmaps support child views or BViews can
draw them)


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


# 96b5c858 12-Jun-2005 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Implemented get_pixel_size_for(). I tested it a bit and it seems correct. I'd be glad if someone reviewed it, though.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13074 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


# 5bac5044 05-Dec-2004 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Fixed warnings and added a comment


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


# c7ee25fd 29-Jul-2004 Jérôme Duval <korli@users.berlios.de>

Splitted Globals.cpp in GraphicsDefs.cpp and InterfaceDefs.cpp to match headers


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


# 636427b614d8c23e5182dcc87883eae1d9d1c6ad 07-Jun-2008 Stephan Aßmus <superstippi@gmx.de>

Axel!! Since _Thursday_ I am trying to track this down. "MediaPlayer wouldn't
play any more clips." Of course I was searching in my own commits. In the
end, I resorted to binary searching revisions for when this broke. Turns out
it is your change r25793/r25794, in which you forgot to attach the colorspace
to the app_server message. Which of course makes it lock up. Another of those
instances where you think passing data structures between client and app_server
instead of this "protocol" would be the better idea...

* Fixed bitmaps_support_space() retrieving the currently supported overlay
flags for a given color space. This makes MediaPlayer play files again, the
media node connection would time out because of the broken app_server
communication. (I have not tested this change yet, but I will in a minute, on
a different computer.)
* Also retrieve the overlay supported flag for YCbCr colorspaces.


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


# 6ec21b4ad380a417f21835299ebb928b8f39a806 03-Jun-2008 Axel Dörfler <axeld@pinc-software.de>

* Implemented retrieving additional bitmap support flags by the app_server.
* Added B_BITMAPS_SUPPORT_OVERLAY flag to indicate overlay support for the
color space.
* Rewrote GraphicsDefs.h - the previous one was obvious a copy of the Be header,
including typos and strange white space. I was a bit lazy with respect to
the color space details, and mostly trusted the information provided by the
Be header else.


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


# 3dd59121c4175b7449c0a6c00433975e60911e30 02-Jun-2008 Stephan Aßmus <superstippi@gmx.de>

Resolved TODO and set the flags for the kind of additional
bitmap support (bitmaps support child views or BViews can
draw them)


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


# 96b5c85819a02e80ad3eb14ba7334a09e715abac 12-Jun-2005 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Implemented get_pixel_size_for(). I tested it a bit and it seems correct. I'd be glad if someone reviewed it, though.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13074 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


# 5bac5044b7bded427e8686a073428900657da83b 05-Dec-2004 Stefano Ceccherini <stefano.ceccherini@gmail.com>

Fixed warnings and added a comment


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


# c7ee25fdcab4f723211646f1e56fdcbbffbc4f19 29-Jul-2004 Jérôme Duval <korli@users.berlios.de>

Splitted Globals.cpp in GraphicsDefs.cpp and InterfaceDefs.cpp to match headers


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