Adapt other code accordingly. Minimum changes to fix ticket #11478
In theory also font height could be fractional, so we might need to
review other parts of the code.
Change-Id: Idbdbe38193ca5a32b3d09c7cf9accfc917760cae
Reviewed-on: https://review.haiku-os.org/821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
These methods and fields are missing from the R4 and R5 Be Book, but are
mentionned in the R4 release notes and present in the R5 headers.
Change-Id: I4de8298449bd66e0ee7fe0b52690552916314123
Reviewed-on: https://review.haiku-os.org/820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When recording into a BPicture (ServerPicture, actually), one cannot
simply record the commands only, when the drawing itself would modify
state. This affects all drawing commands that change the pen location.
Therefore it is necessary to have a way to "dry-run" drawing a string
in order to know the pen location that would result. This is what
these two new methods help achieve.
Change-Id: Ic399a5513f18c12c16c0ab10a55e768c1b30e4e0
Reviewed-on: https://review.haiku-os.org/816
Reviewed-by: Rene Gollent <rene@gollent.com>
When CopyEngine::_CopyFolder() would recursively call itself, the
fCurrentTargetFolder would be set to the entry name of that directory.
When this returned, this was never reset to the parent directory name
and would eventually use a freed string when the BEntry was reused
for the next entry.
When changing the font state, a uin16 mask at the beginning of the
commands encodes which font parameters are transmitted in the link
data. Return this mask, so that one can know what parameters have
changed in the DrawState's ServerFont.
Change-Id: I52a9a665aac8eb0e6505193eba32c4b137846c78
Reviewed-on: https://review.haiku-os.org/814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The constructor calls for GlobalDescriptorTable and
InterruptDescriptorTable were run on each CPU, each time clearing out
any changes already done on other CPUs.
For the IDT this didn't matter as the result would always be the same.
In case of the GDT the result would surprisingly be mostly hidden. The
used GDT entries are for the double fault stacks (which is rarely hit),
the user TLS (which will only be used in compat mode) and the TSS which
is immediately cached in the task register.
The clearing of the GDT allowed for a tiny window of time between
setting up the entry for the TSS and it actually being loaded (and
cached) in the task register. When this happened, the load of the TR
caused a not present fault, which at this point leads to a tripple
fault and reset due to no fault handlers being installed yet.
Fixes#14659.
Change-Id: I6e5c00d412ab17c3ef05740ba71228e6ca266c1e
Reviewed-on: https://review.haiku-os.org/810
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
This was apparently copied from GlobalDescriptorTable::SetTSS() which
needs two table entries and therefore checks for index + 1. For the
SetUserTLS case this isn't needed and would cause aborts when reaching
the maximum CPU count (64 currently).
Change-Id: I27bd777fedadbd3740ac8c791199ec9300b06327
Reviewed-on: https://review.haiku-os.org/809
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The normal locking uses spinlocks that require getting at the current
CPU, which in turn needs a current thread set. This has not been set up
at this point and would simply cause tripple faults.
Use manual locking using atomic ops instead.
Change-Id: Ica894389330ef481eec84b667234139746ac4a46
Reviewed-on: https://review.haiku-os.org/808
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When resending a mail, don't put the To-field in the second column
after the From-field as it's done for incoming mail. To- and From-field
are the same layout as for creating a new mail.
Use the member fResending instead of the parameter "resending" the
THeaderView was called with.
Initialize fCcControl in ctor.
Many of the consumers fill in data into preallocated arrays. Some of
them already ignored values past the array size manually, some didn't.
Add a maxChar argument and set it from the incoming array sizes for
the various consumer cases.
Variable length arrays on the stack are always risky when the length
is indeterminate as they can easily overflow the stack. Replace their
use by BStackOrHeapArray, fixes#6354.
Also replace most other dynamic allocations by BStackOrHeapArray as
it is more convenient and may avoid unnecessary dynamic allocations.
Add allocation checks and early returns to all places while at it.
* 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>
