* Palette is set to Optimal which preserves colors of original
* Write transparent gifs is on which preserves transparency
* Transparent auto is on which automatically detects the transparent color
* default transparent color is 255, 255, 255 (aka white) if you select a
manual transparent color which seems like a more sane default than black.
This allows ShowImage and other programs to save transparent gifs without
removing transparency and without reducing the colors.
Instead of relying on the global protocol loop to call _ParseHeaders
once for each header, extract as much as possible from the current
buffer.
This saves memory, avoids useless operations on the socket and various
processing steps, and fixes#10245.
Also improve the handling of 0-size requests to make sure they terminate
properly.
* Tracker has support for this in its RefsReceived handler, which
results in simpler code than going through BRoster to open the folder.
* Avoids a race condition, possible confusion of Tracker windows with
the same title, and makes the code more readable (and working).
* Fixes#11008.
Thanks to Axeld for pointing the support in RefsReceived, which wasn't
used anywhere outside of Tracker, yet.
* Allow EXECUTE on the Folder property to open a window for the passed
ref and return a BMEssenger targetting that window.
* Allog GET on the Folder property to return a messenger to the matching
window, if one is already open.
* Make scripting support mandatory and remove the define allowing to
disable it.
* Avoids the ugly "button that opens another window" UI paradigm in
Tracker preferences.
* Makes it possible to revert changes to the automount settings as the
Tracker preferences window has a revert button.
- We factor out the code that does the decoding, deinterlacing and color space
converting into its own function. This prepares auto detection of video frame
properties in a later commit. Auto detection means (for example), that you
don't need to know the size of the decoded video frame -before- intitializing
the video codec as it is the case with the current implementation.
- Use the already existent private member variable fHeader to fill out and
return video frame properties.
- Rename some variables to be more self describing.
- No functional change intended.
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit 6beab04f48e98022041895750f38c5a35a5f4f9e)
- As it is rather hard to find useful documentation, on how to use FFMPEG's API
we cut of some research time by just documenting it at the place where it is
most visible to other FFMPEG plugin developers :)
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit b0ed15d2196ca45de8ab2d5913d760602aacc5f3)
- This small refactoring is in preparation for implementing decoding of partial
video frame data, where one needs to preserve encoded data between multiple
calls to AVCodecDecoder::_DecodeVideo().
- Note: The names fChunkBuffer and fChunkBufferSize are open for discussion.
I'd rather prefer fEncodedDataChunkBuffer and fEncodedDataChunkBufferSize.
But I'd like to take small refactoring steps, and changing the naming would
also touch the AVCodecDecoder::_DecodeAudio() function. I'd rather focus
on improving the video part for now, leaving the audio part alone.
- No functional change intended.
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit f2da1e752458b926aebe50642bf6af19e9903f17)
When using the Show Disks icon option, single window navigaton mode,
and starting navigation by the Disks icon, these bugs would occurs
upon entering child poses :
*) The draggable icon at the top right wouldn't appear
*) The file menu wouldn't update properly (for example, the New folder
menu item won't show)
Based in part on dru_ed's patch.
Accidentally renamed these in the header, rename them back to
match the cpp file. These param names might not be very good but
they match the struct variable names. They are private methods
anyway. No functional change intended in either commit.
Besides that this is a nicer interface, it allows us to get a the HPKG
header as a side effect of initializing the reader, thus preventing
seeking backward in the file. This makes "package recompress - <file>"
work.
* Prefix lock functions with __ to mark them as private. Add
forwarding macros to keep existing code working.
* Avoids symbol name clashes with kernel lock APIs, occuring when
using kernellandemu-lib in userlandfs. Thanks to Ingo for the
suggestion.
Until now we always declared in the HPKG header that the package file is
zlib compressed. For uncompressed files we would just store all
individual chunks uncompressed. Now we handle completely uncompressed
files slightly differently: We don't write the redundant chunk size
table anymore. The size savings are minor, but it makes the uncompressed
format read-streamable which may be handy.
* PackageFileHeap{Reader,Writer} as well as Package{Reader,Writer} and
their implementation and super classes do now internally use a
BPositionIO instead of a FD to access the package file. This provides
more flexibility needed for features to come.
* BPackageReader has already grown a new Init() version with a
BPositionIO* parameter.
Simple BPositionIO implementation using the POSIX API on a FD. In effect
similar to BFile, but more easily ported to kernel and boot loader (and
the FD is reusable).
