Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
Just use BControLook where appropriate. It already provides a nice arrow
drawing function (also used in DeskBar expander and in scrollbar
buttons).
Fix second part of #8900
Changes by John Scipione:
Update menu mark and submenu arrow color with menu text color
Use text color for checkmark and submenu arrow colors, tint less black.
This means that colored bg/white text menu item will also draw a white
checkmark and submenu arrow.
Break out BMenuItem::Draw functionality into private methods _IsActive,
_LowColor() and _HighColor() methods and use them to set the mark colors.
Scale submenu arrow and checkmark with item height (which scales with
font size.)
does not align shortcuts with submenu arrows... but if you were to do
that you'd add item->Bounds().Height() / 2.
Signed-off-by: John Scipione <jscipione@gmail.com>
Change-Id: I8299094ef88bf227510b116eb1b84c261dc94723
Reviewed-on: https://review.haiku-os.org/c/341
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().
Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
* I want to introduce a new way for plugins to
register for a format. Supporting the old FormatManager is
too painful at this point and not worth the effort.
* We don't aim to replicate this functionality. I don't
think this will be useful at all in future iterations.
Originally I planned to rewrite it on top of the new
BMediaFormat, but now I am of the hopinion this is
greatly unneeded.
* Adds some missing methods signatures.
* integer vs float framerate is a longstanging debate. In theory,
in digital a/v there should not be need for floating point framerates.
This is because unless the software is run on exoteric hardware, there
is not need for it. Unfortunately, some legacy from the past like the
29.7 hz debate (NTSC) still may need to work under floating point framerates.
Even if in pratice it'd be run at 30 hz anyway.
* In theory, to handle all those correctly we should use a rational framerate,
however most code should be rewritten to support that correctly, and
it'd add some excessive complexities.
* All integer types are reverted back to unsigned ones. There's really
no reason to use signed integers there, and more importantly the danger
for integer underflows and the attached security concerns is very big.
There was no synchronization of the check of the done flag and the
waiting thread suspending to wait for it. It was therefore possible that
the new team both set the flag and triggered the wakeup of the waiting
thread in that time window, causing it to miss both the set flag and the
thread resumption.
Use a condition variable instead.
Fixes#13081.
Change-Id: I93c45db8dd773fe42b45c4b67153bcd39e200d3b
Reviewed-on: https://review.haiku-os.org/803
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows heap implementations to initialize and clean up any thread
specific structures. The current default hoard heap does not use these.
Note that the thread exit hook will not be called for the main thread as
the heap may be needed during process termination (__cxa_finalize for
example).
Change-Id: I703fbd34dec0d9029d619a2125c5b19d8c1933aa
Reviewed-on: https://review.haiku-os.org/799
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This file is included, directly or indirectly, by most of the
kernel-space C++ code, and so importing the entirety of "std"
seriously pollutes the global namespace.
So instead, just import "std::nothrow", which is the only thing
we really want in the global namespace. Tested on both GCC2
and GCC7 and seems to work just fine.
While I'm here, also update the include guards and copyright
header to match the standard format used elsewhere.
I need this to use loopers in WebKit, which spawns threads and expects
to be able to turn them into event loops later on.
This is the pattern already used in BApplication, we may as well make it
available elsewhere.
Change-Id: I5939ca89d33cb3bcc92567b302c2038d976af598
Reviewed-on: https://review.haiku-os.org/735
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Use BStackOrHeapArray instead of using auto_ptr to array.
Change-Id: I171cb002829c36ec51ba7d1e387869263e2a40f2
Reviewed-on: https://review.haiku-os.org/745
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* We try to conform to what ffmpeg does, it is
unuseful to support metadata keys formats which
aren't really used anywhere.
* Add TODO with some infos for future improvements.
* Namespaces protect symbols, I didn't consider that when adding
the BCodecKit namespace, so, the AddOnManager complained that
instantiate_plugin() was missing. A macro is introduced that allow
plugins to specify it's className, version and name, this ease
the declaration of the plugin symbols, otherwise the function
should have been declared inside the BCodecKit namespace which
we would like to avoid.
* The code is also more future proof, since in future the AddOn manager
can begin to check for plugin versions.
Fix 'true / false' value is implicitly cast to the integer type.
Change-Id: I2f72fcd34d2d97d20e2a98ed5efe25919a485c9d
Reviewed-on: https://review.haiku-os.org/739
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* This should be probably uniformed with the future
media kit format defs. Not sure why those formats are
separated and used only by the codec kit. Eventually,
if needed can be changed to some name that differentiate
them better than media defs.
* Move to BCodecKit namespace and make extensive use
of BCodecRoster.
* This is a first step in the right direction of
decreasing private dependencies. Some APIs are being
translated to the CodecKit. I am doing an investigation
on which APIs are really used among apps, so that the new
kit can be more slim and oriented toward easy development
and can be extended in the right direction instead to
continue maintaning unuseful code.
* BMediaFormats needs still a bit of love.
* General improvements in style and code maintainability.
This allows Clang builds (linked with our cross binutils) to
at least start runtime_loader and then try to load launch_daemon.
That fails with an infinite loop somewhere...
This doesn't fully work yet (the FS code in libroot_build
needs to be adapted, as some of the symlink-related calls
are not available on MinGW), but it gets much further than
the "Cygwin" target did.
These have been broken for a long time. Some Cygwin changes that
are relevant on MinGW are kept here, but users on Windows who
want to build Haiku should probably use WSL at this point.
However, now that we are using relative paths and don't need
to worry about drive path kludges, it's actually possible to
get some host tools built on MinGW. Changes for that coming.
