The Realize() will change the toolbar size on macOS, which may trigger VideoDisplay::Render and VisualToolDrag::UpdateToggleButtons. Therefore, if we want to call Realize, it must be after setting VideoDisplay::tool and calling VisualTool::SetToolbar. Otherwise, the first will cause an infinite recursion from if(!tool) condition in VideoDisplay::Render, the latter will cause NULL dereference (because VisualToolDrag::toolbar is not set yet).
On the other hand, we do not need to call Realize here at all. If the toolbar does not show, we don't need to call Realize. If the toolbar will show, then Realize will be called by VisualTool after adding their buttons, in VisualTool::SetToolbar.
So we remove the Realize() call from VideoDisplay::SetTool.
Fixwangqr/Aegisub#21Fixwangqr/Aegisub#44
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.
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
wangqr