[Type: Refactoring]
[Scope: src/Tizen.Multimedia.MediaCodec]
[Priority: 🟡 Improvement]
[Lens: Performance, Modernization, Clean Code]
Observation
MediaCodec.GetCodecType<T> and CheckMimeType<T> use dynamic + Convert.ChangeType purely to dispatch to the correct TypeConverter.ToNative overload, even though both public callers already pass a concrete enum type.
// src/Tizen.Multimedia.MediaCodec/MediaCodec/MediaCodec.cs : 421-443
private MediaCodecTypes GetCodecType<T>(T mimeType, Type type, bool isEncoder)
{
dynamic changedType = Convert.ChangeType(mimeType, type);
int codecType = TypeConverter.ToNative(changedType);
Native.GetSupportedType(_handle, codecType, isEncoder, out int value)
.ThrowIfFailed("Failed to get supported media codec type.");
return (MediaCodecTypes)value;
}
private bool CheckMimeType<T>(Type mimeType, T value)
{
if (!Enum.IsDefined(mimeType, value))
{
throw new ArgumentException($"The mime type value is invalid : { value }.");
}
dynamic changedType = Convert.ChangeType(value, mimeType);
var codecType = TypeConverter.ToNative(changedType);
return Enum.IsDefined(typeof(SupportedCodecType), codecType);
}
The two public entry points already know the concrete type:
public MediaCodecTypes GetCodecType(bool encoder, MediaFormatVideoMimeType type) { ... GetCodecType(type, typeof(MediaFormatVideoMimeType), encoder); }
public MediaCodecTypes GetCodecType(bool encoder, MediaFormatAudioMimeType type) { ... GetCodecType(type, typeof(MediaFormatAudioMimeType), encoder); }
Problem
- Performance:
dynamic pulls in the DLR / Microsoft.CSharp call-site infrastructure, incurs first-call binding cost, and Convert.ChangeType boxes the enum on every call — all to re-select an overload the caller already knows statically. (Convert.ChangeType(mimeType, type) here is essentially an identity conversion: type == typeof(T).)
- Clean Code / Modernization:
dynamic obscures which TypeConverter.ToNative overload runs and adds a needless generic + Type parameter that merely mirrors typeof(T).
This is a query/config-time API (not a per-frame path), so the win is correctness/clarity + removing the DLR dependency rather than a per-frame hot-path saving.
Proposed Improvement
Drop dynamic/Convert.ChangeType and call the concrete TypeConverter.ToNative overload directly from each strongly-typed public method (or via non-generic private helpers taking the already-resolved int codecType).
Before
return GetCodecType(type, typeof(MediaFormatVideoMimeType), encoder);
// ...
private MediaCodecTypes GetCodecType<T>(T mimeType, Type type, bool isEncoder)
{
dynamic changedType = Convert.ChangeType(mimeType, type);
int codecType = TypeConverter.ToNative(changedType);
...
}
After
// strongly-typed call sites compute codecType directly:
int codecType = TypeConverter.ToNative(type); // overload resolved at compile time
return GetCodecType(codecType, encoder);
// ...
private MediaCodecTypes GetCodecType(int codecType, bool isEncoder)
{
Native.GetSupportedType(_handle, codecType, isEncoder, out int value)
.ThrowIfFailed("Failed to get supported media codec type.");
return (MediaCodecTypes)value;
}
CheckMimeType similarly validates with Enum.IsDefined(typeof(SupportedCodecType), TypeConverter.ToNative(type)).
Target Files
src/Tizen.Multimedia.MediaCodec/MediaCodec/MediaCodec.cs
Expected Impact (Quantitative Metrics)
- DLR call-site init + boxing
Convert.ChangeType per call: 2 dynamic sites → 0
- Removes the
Microsoft.CSharp dynamic dependency from this call graph.
- Allocation per
GetCodecType/CheckMimeType call: 1 box → 0.
API Compatibility Check
- Public API signature change: none (only private helpers
GetCodecType<T>/CheckMimeType<T> are reshaped; the public GetCodecType(bool, MediaFormat*MimeType) overloads are unchanged)
- Behavior change: none (same native codecType, same
ArgumentException on invalid type)
- Tizen API Level floor: maintained
Impact Scope
- Private helpers:
GetCodecType<T> and CheckMimeType<T> — used only inside MediaCodec.cs (2 callers each). No external/cross-assembly callers.
- Same-assembly only.
Auto-generated by the TizenFX AI refactoring discovery pipeline (scan date 2026-06-07).
[Type: Refactoring]
[Scope: src/Tizen.Multimedia.MediaCodec]
[Priority: 🟡 Improvement]
[Lens: Performance, Modernization, Clean Code]
Observation
MediaCodec.GetCodecType<T>andCheckMimeType<T>usedynamic+Convert.ChangeTypepurely to dispatch to the correctTypeConverter.ToNativeoverload, even though both public callers already pass a concrete enum type.The two public entry points already know the concrete type:
Problem
dynamicpulls in the DLR /Microsoft.CSharpcall-site infrastructure, incurs first-call binding cost, andConvert.ChangeTypeboxes the enum on every call — all to re-select an overload the caller already knows statically. (Convert.ChangeType(mimeType, type)here is essentially an identity conversion:type == typeof(T).)dynamicobscures whichTypeConverter.ToNativeoverload runs and adds a needless generic +Typeparameter that merely mirrorstypeof(T).This is a query/config-time API (not a per-frame path), so the win is correctness/clarity + removing the DLR dependency rather than a per-frame hot-path saving.
Proposed Improvement
Drop
dynamic/Convert.ChangeTypeand call the concreteTypeConverter.ToNativeoverload directly from each strongly-typed public method (or via non-generic private helpers taking the already-resolvedint codecType).Before
After
CheckMimeTypesimilarly validates withEnum.IsDefined(typeof(SupportedCodecType), TypeConverter.ToNative(type)).Target Files
src/Tizen.Multimedia.MediaCodec/MediaCodec/MediaCodec.csExpected Impact (Quantitative Metrics)
Convert.ChangeTypeper call: 2 dynamic sites → 0Microsoft.CSharpdynamic dependency from this call graph.GetCodecType/CheckMimeTypecall: 1 box → 0.API Compatibility Check
GetCodecType<T>/CheckMimeType<T>are reshaped; the publicGetCodecType(bool, MediaFormat*MimeType)overloads are unchanged)ArgumentExceptionon invalid type)Impact Scope
GetCodecType<T>andCheckMimeType<T>— used only insideMediaCodec.cs(2 callers each). No external/cross-assembly callers.Auto-generated by the TizenFX AI refactoring discovery pipeline (scan date 2026-06-07).