* The ASSERT() I introduced in r44585 was incorrect: when the sub transaction
used block_cache_get_empty() to get the block, there is no original_data for
a reason.
* Added a test case that reproduces this situation.
* The block must be moved to the unused list in this situation, though, or else
it might contain invalid data. Since the block can only be allocated in the
current transaction, this should not be a problem, though, AFAICT.
- BNavMenu now keeps its own copy of the cached types list that's passed to it.
In some circumstances it could happen that the container window would
delete the list and consequently the nav menu would wind up with a pointer
to an invalid object. Probably a regression from the async mouse tracking
rewrites.
* avoid mixing input and output paths when building a tree. In fact, an
audio input shouldn't use only a mixer used for output.
* in case an audio input has more than one input, use these inputs to
build a mux control.
* should help with #8270, #8333
The lowest 4 bits of the MSR serves as a hint to the hardware to
favor performance or energy saving. 0 means a hint preference for
highest performance while 15 corresponds to the maximum energy
savings. A value of 7 translates into a hint to balance performance
with energy savings.
The default reset value of the MSR is 0. If BIOS doesn't intialize
the MSR, the hardware will run in performance state. This patch
initialize the MSR with value of 7 for balance between performance
and energy savings
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* In cache_abort_sub_transaction(), the original_data can already be freed
when the block is being removed from the transaction.
* block_cache::_GetUnusedBlock() no longer frees original/parent data - it
now requires them to be freed already (it makes no sense to have them still
around at this point).
* AFAICT the previous version did not have any negative consequences besides
freeing the original data late.
* cache_abort_sub_transaction() was setting the transaction_next pointer to
NULL in order to remove a block from a transaction -- however, it forgot to
actually remove it from the transaction's block list.
* Minor restructuring.
Several scenarios of misbehaviour found and fixed, examples :
* Deleting an item sitting before the currently playing item had the effect of
starting the playback of the item before the delete item.
(now it just updates the indexes - setting it to fCurrentIndex - 1 - without altering playback).
* Deleting the last item of the list had for effect of starting the playback of the entry
newingly being the last entry, regardless if the last entry was the active one or not.
Should fix#6689.
All controls were enabled when toggling fullscreen on and off;
now it recalls the argument last used in SetEnabled() and reuse it
when called in AttachedInWindow() (which occurs in such toggling)
Fixes#8804.
