The code was for wxCocoa, which is a dead implementation of wxWidgets. wxOSX/Cocoa does not need this hack anymore. And the code is causing linking errors due to using private structures in wxCocoa.
Revert fffb138b81
Previously, when reading font data, we only set FaceName to the matched font. When we are using some font with special font weight (e.g. @Source Han Sans J Heavy), if we do not correct the font weight in the LOGFONTW struct, then subsequent call to get_font_data will fall back to default font. This causes wrongly matching Arial.ttf to any font that does not provide standard font weights.
Instead of only correcting FaceName using the matched font, we simply use the first matched font, thus the FaceName, Weight, CharSet, etc. will all be correct. This also eliminates the memcpy.
Previously, Render is called every time when the content is updated from event callbacks. So simply moving the mouse around will spam the event queue and cause video stuck. Now we do render in render callback, and only set a flag to indicate the need of re-render.
There was some magic bit operations to calculate the cache block offsets. This only works when both bytes_per_sample and channels are power of 2. Originally the format is assumed to be int16 mono, which satisfies this requirement. However in case we use original audio data, the channels can be something not a power of 2 (e.g. for 5.1 channel audio the number of channels is 6). This will break the calculation. We rewrite the calculation, without using those bit operations.
lj_str_new() had a separate fast-path and slow-path. This was bad
because (a) the fast-path was complex and (b) the fast-path was
actually slower than the slow-path in practice and (c) in practice it
could cause confusing performance problems depending on the memory
alignment of any often-reused string buffers in a program.
This change specifically makes the 'life' benchmark faster and more
robust to memory layout.
Most code assumes the audio provider is providing int16 single channel audio data, without actually checking them. In this commit, we add a new function to provide the needed int16 mono data with checking.
This will give a more natural indication of where the position is. When dragging with mouse, now the thumb block will always center under the mouse position.
Fixwangqr/Aegisub#26
In 888be0607f some changes have been made to video_display.cpp which causes infinite recursion: the video display enables video/tool/cross tool when running VideoDisplay::Render() for the first time.
But when setting up the tool, the video box size is changed, which calls VideoDisplay::Render() again. So we need to set the tool BEFORE it modifies the box by "AddSeparator".
Fixwangqr/Aegisub#21
Co-authored-by: Charlie Jiang <cqjjjzr@126.com>
