* Our media kit is designed to work with packed audio: which means the
samples from different channels are interleaved in a single stream
* Old ffmpeg versions also used this, but they now switched to the
planar format, where each channel is stored separately.
* Fortunately, we can request ffmpeg to use the packed format. We
actually already tried to do that, but the API for requesting a sample
format has also changed.
* Finally, we didn't recognize the packed format reported by the codecs,
which in some cases could lead to 16/32 bit mismatches on top of the
planar/packed mixup.
Fixes audio with ffmpeg 2.8 (ticket #12460)
* If the same shape alpha mask is set again and again, we now keep
the rendered masks in a cache. On certain websites, WebKit sets
the same shape for clipping hundreds of times, which uses a lot
of time to render the masks.
* When a shape mask was generated, we put it into AlphaMaskCache.
The constructor for ShapeAlphaMask is made private and a factory
method is used for instantiation instead, which transparently
looks up in the cache whether a suitable mask was already generated
before (so the entire caching is encapsulated inside the AlphaMask
class).
* When taking a mask out of the cache, we still create a new
AlphaMask instance. However, the new instance will share the
mask bitmap with the previously generated instance (aside from
the rendering of their bitmap, AlphaMask instances are pretty
lightweight). Shape masks are only seen as identical when
their shape is the same, the inverse flag, and they have the
same parent mask.
* Cache is limited to a fixed size of currently 8 MiB, using a
simple random replacement scheme. An LRU scheme can be added in
the future if necessary. Counting of bytes for the cache size
includes parent masks of masks in the cache, even if the parent
itself is not cached. A reference counter for "indirect" cache
references keeps track of which masks are not part of the cache,
but still need to be added to the cache byte size.
* For now, only for ShapeAlphaMasks, other mask types can be added
as necessary.
* If there is an empty clipping region (invalid clipping) for the
current view, a new layer could still be started, but not ended
anymore. That's because unlike begin layer, end layer is handled in
_DispatchViewDrawingMessage (because it can do actual drawing)
and this method checks whether the clipping is valid and bails out
if it isn't.
* Add an exception for the AS_VIEW_END_LAYER command code to still
process it even when the clipping is invalid. The layer itself
can after all set a valid clipping later on when its command list
is played back. And even if it doesn't, we still have to play it
to make sure nested layers are cleaned up.
* Fixes the memory leak in #12460 where webkit creates
said situation: it had a layer open and then the closing was
ignored due to empty clipping. All subsequent layer calls created
nested layers in that one, hundreds of them, and their BPictures
contained bitmaps, quickly eating up and leaking hundreds of MiB
in app_server.
* When a layer has opacity 0, we can't just ignore it, we still
have to play back its picture, even if the drawing will never
appear on screen. This is because there might be nested layers
and if they don't get blended, their references are not released.
Also, it can be argued that state changes in the layer should be
applied even if the layer is invisible (if we ignore it there,
it would be inconsistent with other layers).
This edge case of invisible layers could be optimized further, but
it is rare enough anyway, so this should do.
* OffscreenCanvas was not deleting its DrawState. Found thanks to
the allocation tracking feature in libroot_debug (thanks mmlr!)
* Also a missing nothrow and a missing ref release in an error case
* Making the alpha masks independent of view size is a good thing,
however it turns out that I was too optimistic about the
consequences: webkit sometimes sets masks for the whole page, not
just the currently visible area. E.g. on Github diff views, it
was seen to set a clipping path which is about 1,000 x 10,000
pixels in size. Generating these huge masks eats up lots of memory
and time.
* We now clip the alpha masks to the current view size. This
introduces a dependency between mask and view again, however a
weaker one than it used to be before the mask rework. When the
view is enlarged, and the alpha mask was previously clipped during
rendering, we regenerate it at the new size. When the view is
shrunk however, we don't do anything and just keep the
now larger than necessary mask around (so we don't have to
regenerate again when the view is subsequently enlarged again --
except if it then becomes even larger than it used to be).
Changing the view origin is unaffected and still doesn't cause a
regenerate.
* This is used when configuring the DNS client, so resolving will not
work
* It is supposed to be a control for entering IPs, not domain names.
Fixes#12464.
When quitting the app or closing the last window, all windows and tabs
are stored in a "Session" file. This is reloaded when the browser
starts, allowing to restore all windows and tabs.
Limitations: the page content and navigation history are not saved. The
file is written only at exit so this can't be used for crash recovery
(but you can make a backup of your default session).
Fixes#6680.
When a translator is uninstalled, BTranslatorPrivate::_RemoveTranslators is
called. This method used to unload the image containing the translator after
calling Release() on it resulting in several problems:
- If the translator was still busy, e.g. translating something while being
installed, it crashed since the image was unloaded even though its refcount
was larger than 0.
- Applications using code from one of the translators (e.g. its config view)
would crash when the translator is uninstalled (this is bug #12005).
This problem is now fixed. The roster keeps track of all translators whose
image it manages (even if the translator was already removed from the roster).
It also keeps a refcount to all images. When a translator's refcount drops to
zero and it belonged to a roster at some point, it does not delete itself, but
notifies the roster that it is ready to destruct, which then removes it from
the roster if the translator is still in it, destroys the translator, decrements
the refcount of the image and if the new refcount is zero, unloads the image.
All of this is done in a message handler, since if the translator called
TranslatorDeleted like before, the unloaded image would be referenced when
the stack is walked up.
Finally, the DataTranslations preflet is required to Acquire() the translator
whose config view it is showing, because otherwise its refcount could be reduced
to 0 and the image unloaded. BTranslatorRoster now enables users to acquire a
translator by ID. By the time the translator has to be released, it might not
be part of the roster anymore though. Since BTranslatorRoster tries not to give
out raw pointers to the translators it manages, users who acquire a translator
through a roster now are given a BTranslatorReleaseDelegate, which allows for
releasing the BTranslator exactly once and then self-destructs.
Signed-off-by: Axel Dörfler <axeld@pinc-software.de>
* Allows you to view and delete cookies.
* The list of domains is hierarchized and collapsed to minimize the
number of empty entries
* All cookie parameters are shown for each domain: name, path, value,
expiration date, and known flags.
The cookie jar used to be locked whenever an iterator was instanciated.
This didn't work well when using several iterators in the same thread,
because the BLocker then allows all of them to access the list
concurrently.
Rework the locking code to use a more fine grained approach, where the
cookie jar is only locked temporarily by methods which require it. These
methods are the ones which get and put new domain-lists in the jar, as
well as acquiring the locks on the domain-lists.
Each domain-list in the jar is locked using a read/write lock as before.
This means there can be many requests getting cookies for the same
domain in paralel, but only one at a time is allowed to set new cookies.
The iterators keep domain lists they need to access read-locked, as long
as they iterate the cookies for that domain.
A limitation of this approach is that deleting a domain-list when it
becomes empty is difficult. We can live with this, however, the
iteration still works (it just skips empty lists), and the empty lists
will not be stored or restored when archiving the cookie jar.
* _SetLaunchStatus() doesn't allow to set the status to B_NO_INIT
(and rightly so).
* Therefore, we now reset it manually in Job::TeamDeleted(). This
fixes restarting things that once ran on demand.
* Also update the port message when the default port changes.
BMessageValueNode:
- When resolving a pointer field, look up the type by the fully qualified
name, as that's how it winds up being stored in the lookup map. Also,
due to gcc omitting the unspecified parent type on such pointers entirely,
looking them up by base type name this way won't work anyhow.
* Since the last change, the user launch_daemon would talk to the
registrar again.
* However, this also caused BRoster::Launch() to preregister the app,
which messed up our preallocated port.
* BRoster::Private::Launch() now allows to get the port that the
registrar created in such a case, and the launch_daemon will now just
use that one as default port.
* This lets us talk to the Deskbar again, and should fix#12455, as
well as #12454 (again).
Tested with a 5MB image, seems to work.
There seems to be an issue with too long names though, or possibly names with spaces.
Also, technically it supports FAT12,16 and 32, so it should probably be renamed
in the interface.
Didn't check how to declare support for more than 1 partition types either.
* These are the standard types used in HTML5 media, tell everyone that
we can handle them.
* A few more green items in html5test.com, no extra points since none of
the formats are mandatory however.
