Previously we had the `profilerViewModel.setProfilerState` call inside the
dismiss method. Because of this it was updating the profiler state prematurely
when user was pressing "upload profile" button and then returning home quickly.
After decoupling the dismiss and setProfilerState calls, now we only update the
profiler state once the profiler state changes, which makes sure that profiler
states in geckoview and ProfilerViewModel stay in sync.
Differential Revision: https://phabricator.services.mozilla.com/D206647
Previously we had the `profilerViewModel.setProfilerState` call inside the
dismiss method. Because of this it was updating the profiler state prematurely
when user was pressing "upload profile" button and then returning home quickly.
After decoupling the dismiss and setProfilerState calls, now we only update the
profiler state once the profiler state changes, which makes sure that profiler
states in geckoview and ProfilerViewModel stay in sync.
Differential Revision: https://phabricator.services.mozilla.com/D206647
According to what Widevine told us, `kProtectionNone` will cause playback
to stop if HDCP_V1 is required. Therefore, we would report HDCP protection
if there is no potential capturing.
Differential Revision: https://phabricator.services.mozilla.com/D207483
There are modifications needed for PDMfactory and the decoder modules in
order to run their methods on non-mainthread and keep them threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D206420
ar -> ae378800d511c0ef32246d14d45b320e867e7142
da -> daa4acbfcef916d586a5ffe0089ce313c2f70750
he -> cef35859975c209ba934c4ad309d4e6c8ad03d77
sl -> 7710d552adcec2fee80da161f1f8a5bc5267074e
uk -> 61f998460dd2c2639eae869a5afa8f3120fc8047
According to what Widevine told us, `kProtectionNone` will cause playback
to stop if HDCP_V1 is required. Therefore, we would report HDCP protection
if there is no potential capturing.
Differential Revision: https://phabricator.services.mozilla.com/D207483
Initially, *vpx_config.c* on various platform-architecture combinations
was revmoed from the input list for source list generation and later
added to the source list in moz.build. This was necessary because the
generated list was based solely on architecture, while the vpx_config.c
differed across platform-architecture combinations.
With the source list generation reworked in the previous patch, each
platform-architecture combination now has its own list. Therefore,
vpx_config.c can be directly included in the source list, simplifying
the process.
Differential Revision: https://phabricator.services.mozilla.com/D207183
Previously, source lists on different platforms were generated solely
based on architecture. Each architecture's source list would be copied
to lists on various platforms with the same architecture, with
modifications as necessary. However, with recently divergent settings
for platforms sharing the same architecture, maintaining a single list
and modifying it across different platforms becomes cumbersome.
To streamline this process and accommodate differing platform-specific
settings, this patch introduces a new approach. It generates source
lists for each platform-architecture combination. Consequently, source
lists for all platform-architecture combinations can be directly copied
without subsequent modifications. This simplifies maintenance across
different platforms and architectures.
Differential Revision: https://phabricator.services.mozilla.com/D206719
This simplifies the common infrastructure, removes two varyings from the common set and will allow other patterns to handle sampling differently if they need it (for example an upcoming repeating pattern).
In addition:
- the color parameter is always passed to the fragment shader (it used to be only when no uv_rect was passed).
- v_flags was reorganized a bit so that w is used by the common infrastructure and xyz are available for patterns to use.
Differential Revision: https://phabricator.services.mozilla.com/D206098
