WPF: замена шаблонов управления повышает производительность, эффективность?

Question

У меня есть общий вопрос о производительности WPF. У нас есть относительно простая форма применения. Некоторые члены команды считают, что переработка шаблонов для базовых элементов управления повысит производительность и ремонтопригодность. Одним из предпочтительных методов является создание нескольких шаблонов управления для элемента управления и их замена с помощью триггеров. Убеждение в том, что меньшее визуальное дерево будет более результативным.

Например, шаблон флажок теперь два шаблона, один проверил и один непроверенный:

<ControlTemplate x:Key="CheckedCheckBoxCT" TargetType="{x:Type CheckBox}"> 
    <Grid x:Name="gLayoutRoot" VerticalAlignment="Center" HorizontalAlignment="Left"> 
     <Grid.ColumnDefinitions> 
      <ColumnDefinition x:Name="colCheck" /> 
      <ColumnDefinition x:Name="colContentLabel" /> 
     </Grid.ColumnDefinitions> 
     <Rectangle x:Name="rectOuter" 
       Stroke="{TemplateBinding BorderBrush}" 
       StrokeThickness="0.5" 
       Fill="White" 
       Width="13" Height="13" /> 
     <Rectangle x:Name="rectInner" 
       Stroke="{TemplateBinding OpacityMask}" 
       StrokeThickness="0.5" 
       Width="9" Height="9" 
       Fill="{TemplateBinding Background}"/> 
     <Path x:Name="CheckMark"     
        Data="{DynamicResource CheckSymbol}" 
        Fill="{TemplateBinding Foreground}"/> 
     <ContentPresenter x:Name="cpContent" /> 
    </Grid> 
</ControlTemplate> 

, а затем бесконтрольно (обратите внимание, что нет никакого элемента пути):

<ControlTemplate x:Key="CheckBoxCT" TargetType="{x:Type CheckBox}"> 
    <Grid x:Name="gLayoutRoot" 
      VerticalAlignment="Center" 
      HorizontalAlignment="Left"> 
     <Grid.ColumnDefinitions> 
      <ColumnDefinition x:Name="colCheck" /> 
      <ColumnDefinition x:Name="colContentLabel" /> 
     </Grid.ColumnDefinitions> 
     <Rectangle x:Name="rectOuter" 
        Stroke="{TemplateBinding BorderBrush}" 
        StrokeThickness="0.5" 
        Fill="White" 
        Width="13" Height="13" /> 
     <Rectangle x:Name="rectInner" 
        Stroke="{TemplateBinding OpacityMask}" 
        StrokeThickness="0.5" 
        Fill="{TemplateBinding Background}" 
        Width="9" Height="9" /> 
     <ContentPresenter x:Name="cpContent" 
        Margin="5,0,0,0" 
        VerticalAlignment="Center" 
        Grid.Column="1" /> 
    </Grid> 
</ControlTemplate> 

Существует аналогичное обсуждение создания текстового поля только для чтения с возможностью выбора текста, с использованием триггеров для замены текстового блока (который вы не можете выбрать из текста) с текстовым полем.

Действительно ли это повышает производительность до какой-либо заметной степени? С помощью флажка будет триггер, чтобы показать/скрыть проверку, а не два разных шаблона управления, примерно одинаково или лучше?

Мне действительно все равно, но похоже, что много сложностей добавлено для получения большого выигрыша. Мне было любопытно, что мнения других были, особенно. если они основаны на объективном опыте. (Вы можете видеть, что меня не волнует, чтобы настроить некоторые примеры приложений и проверить их эффективность. :))

Спасибо!

Answer 1

blog post Обсуждаются проблемы с производительностью в отношении Visual Studio, они отмечают, что упрощение визуального дерева не было чем-то большим, чем они выглядели. В вашем примере я думаю, что наличие двух шаблонов для флажка будет препятствовать, а не улучшать ремонтопригодность, так как изменение внешнего вида потребует изменений для обоих. Также переключение шаблона при нажатии, скорее всего, будет медленнее, чем настройка видимости элемента.

Что касается общей производительности, я бы обратил больше внимания на Effects, VisualBrushes и т. Д., Но упростил использование шаблонов (ItemTemplates), если ситуация с текстовым полем только для чтения находится в ItemControl с большим количеством элементов и большинства был бы отключен, я был бы склонен это делать. Существует немало ресурсов относительно производительности WPF, в том числе упоминаемых в этой статье.