<p>Xamarin.Forms 드로잉 사양</p>

에 만든 2018년 04월 13일 · 69코멘트 · 출처: xamarin/Xamarin.Forms

Xamarin.Forms 드로잉 사양

테마

MaterialShell이 작동하도록 하려면 머티리얼 디자인으로 보이는 셸이 필요할 뿐만 아니라 모든 내용도 머티리얼 디자인이어야 합니다. 오늘날 그것은 커스텀 렌더러를 의미합니다. 이것은 무겁고 사용자 작업 관점에서 바람직하지 않습니다. 대신 더 나은 접근 방식이 필요합니다.

간단한 그리기 API 샘플

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button>
</Button>

적어도 현재로서는 보기 템플릿이 DrawingTemplate 여야 합니다. DrawingTemplate 의 첫 번째 자식은 항상 Drawing 입니다. Drawing 내부에서 레이아웃과 드로잉 프리미티브를 사용할 수 있습니다.

그리기 프리미티브는 x:named일 수 있고 이름으로 조회되고 다른 View 처럼 코드 숨김에서 조작될 수 있습니다. 실제로 그리기 프리미티브는 렌더러가 없고 작동하려면 Drawing 안에 있어야 하는 단순한 보기입니다. Drawing 는 모두 간단한 그리기 명령으로 축소되므로 지원할 수 있는 어린이로 제한됩니다.

기본 개체를 그릴 때 색상/배경 등을 제공하기 위해 색상 유형이 아닌 브러시 유형을 사용할 수 있습니다.

MaterialShell을 사용할 때 모든 관련 컨트롤은 기본 Template 를 받게 됩니다. 이 컨트롤은 머티리얼 디자인 지침에 따라 테마를 지정하고 플랫폼 전체에서 모양과 느낌을 통합합니다. 이 테마는 리소스 사전에서 전파를 차단하여 계층 구조의 모든 계층에서 무시할 수 있습니다.

DrawingTemplated 컨트롤은 때때로 다른 렌더러를 필요로 할 수 있으므로 일단 실현되면 컨트롤의 템플릿이 변경되지 않을 수 있습니다.

유형

드로잉 템플릿

이것은 대부분 마커 유형입니다. 앞으로 템플릿이 DrawingTemplate이어야 한다는 요구 사항을 제거할 것입니다.

public class DrawingTemplate : ControlTemplate {}

그림

렌더러가 없고 대신 상위 뷰에서 기본 도면으로 사용하는 뷰입니다. Drawing은 측정할 수 있는 매우 기본적인 레이아웃이지만 레이아웃할 때 항상 모든 자식의 크기를 자신과 같은 크기로 조정합니다.

public class Drawing : Layout<View> {}

보기에서 그리기를 위한 새 API

public class View : VisualElement // new API only
{
  public ControlTemplate Template { get; set; }

  protected BindableObject GetTemplateChild(string childName);

  protected virtual void OnApplyTemplate ();
}

브러시

public class Brush : BindableObject
{
  public static readonly BindableProperty OpacityProperty;
  public double Opacity { get; set; }
}

솔리드컬러브러시

public class SolidColorBrush : Brush
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }
}

그라디언트 브러시

public class LinearGradientBrush : Brush
{
  public static readonly BindableProperty GradientStopsProperty;
  [Content]
  public GradientStopCollection GradientStops { get; set; }
}

GradientStopCollection

public sealed class GradientStopCollection : IEnumerable<GradientStop>, IList<GradientStop>

GradientStop

public sealed class GradientStop : BindableObject
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }

  public static readonly BindableProperty OffsetProperty;
  public double Offset { get; set; }

  public static readonly BindableProperty StartPointProperty;
  public Point StartPoint { get; set; }

  public static readonly BindableProperty EndPointProperty;
  public Point EndPoint { get; set; }
}

드로잉 프리미티브

연관된 속성이 있는 많은 수의 그리기 기본 요소가 필요합니다. 이 문서는 그것들을 모두 정의하려고 하지 않고, 존재해야 할 명백한 것들 중 일부만 기록해 두십시오. 드로잉 기본 API는 SkiaSharp를 완전히 대체하기 위한 것이 아닙니다. 그러나 Skia 또는 paltform에 대한 기본 드로잉 백엔드 사용에 불가지론적입니다.

Skia를 위한 좋은 경로는 Skia를 통해 드로잉을 렌더링 하도록 지시 하는 SkiaDrawing 요소를 추가 하는 것입니다. 그런 다음 Skia는 모든 스톡 프리미티브를 렌더링하고 코딩된 드로잉을 허용하는 Skia 드로잉 요소를 제공할 수 있습니다.

모양

namespace Xamarin.Forms.Shapes 
{
  public class Shape : View
  {
    public static readonly BindableProperty FillProperty;
    public Brush Fill { get; set; }

    public static readonly BindableProperty StrokeProperty;
    public Brush Stroke { get; set; }

    public static readonly BindableProperty StrokeThicknessProperty;
    public double StrokeThickness { get; set; }
  }
}

선

namespace Xamarin.Forms.Shapes 
{
  public sealed class Line : Shape
  {
    public Point Start { get; set; }
    public Point End { get; set; }
  }
}

타원

namespace Xamarin.Forms.Shapes 
{
  public sealed class Ellipse : Shape
  {
  }
}

텍스트

public sealed class Text : Shape 
{
  // All the same properties as Label more or less
}

직사각형

namespace Xamarin.Forms.Shapes 
{
  public sealed class Rectangle : Shape
  {
    public CornerRadius CornerRadius { get; set; }
  }
}

베지어선

이것은 UWP와 상당히 다르지만 베지어 곡선 경로/모양뿐만 아니라 일반 다각형 및 폴리라인을 그릴 수 있습니다.

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierLine : Shape
  {
    public IList<BezierPoint> Points { get; }
    public bool ShouldClose { get; set; }
  }
}

베지어포인트

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierPoint : Point
  {
    public Size LeftControlOffset { get; set; }
    public Size RightControlOffset { get; set; }
  }
}

할 것

[x] 그리기용 API 추가
[x] 브러시 API 작성

문제

모양

호만 그리는 좋은 방법은 없습니다. 이것을 하기 위한 UWP의 메커니즘은 약간... 어, 재미가 없습니다.

Shapes가 현재 Views라는 사실에 대해서도 할 말이 있습니다. 이것은 사용자가 새로운 레이아웃 메커니즘을 배울 필요가 없기 때문에 좋은 표준 레이아웃에서 사용할 수 있는지 확인하기 위한 것입니다. 단점은 드로잉 프리미티브가 드로잉의 컨텍스트에서만 작동하지만 컴파일러가 드로잉 외부에서 사용하는 것을 막지는 않는다는 것입니다. 반대 사례는 현재 더 큰 악으로 보이는 Drawing 특정 레이아웃을 만드는 것입니다.

이상적으로 레이아웃은 View 및 Drawing Primitives가 구현할 일부 ILayoutable 인터페이스를 구현하는 모든 자식을 허용합니다. 그러나 이것은 주요 변경 사항이므로 현재로서는 View가 실행 가능한 유일한 옵션인 것 같습니다.

브러시

ImageBrush가 필요할 것입니다. 모든 플랫폼이 브러시가 사용되는 모든 곳에서 ImageBrush를 지원할 수 있는지 확인하기 위한 연구가 필요합니다.

드로잉 템플릿

현재 필요한 속성을 기반으로 렌더러를 전환하는 메커니즘이 코어에 없습니다. 추가해야 합니다. 이상적으로는 템플릿 기반 스위치보다 더 일반적이어야 합니다.

brushes shapes in-progress high impact enhancement ➕

출처

jassmith

👍28 ❤18 🎉9 👎1

가장 유용한 댓글

이것은 Material Shell이 이것에 의존하기 때문에 Material Shell보다 먼저 일어나야 합니다. Shell보다 먼저 이것을 보고 싶다고 말씀하신 것 같은데요?

Shell은 더 빠르고 쉽게 시작하는 데 중점을 두지 않습니다. 페이지를 자체적으로 제어할 수 없는 방식으로 페이지를 현대화하기 위한 것입니다. 기본적으로 완전히 대체하기 위한 것이며 사람들이 이식을 고려하도록 권장할 것입니다. Shell은 최종 사용자에게 훨씬 더 부드럽고 풍부한 경험을 제공하는 데 중점을 두고 있으며 애니메이션을 사용자 정의할 수 있으며 애니메이션 전후에 로드를 지연/지연하여 딸꾹질을 제공하지 않도록 할 수 있습니다. 그것은 안드로이드에서 0 GPU 오버드로 콘텐츠 영역을 제공하는데, 이것을 오버드로가 차트의 "빨간 go fuck yourself" 부분에 있는 현재 페이지와 비교하십시오.

Shell은 사람들이 더 빨리 시작하도록 하는 것이 아니라 앱을 더 빠르게 만드는 것입니다. 예를 들어 Shell을 사용하면 페이지/탭/그룹을 "자주"로 표시할 수 있으며 사용자가 지속적으로 방문한다는 가정 하에 시스템에서 유지합니다. 즉, 다른 곳으로 이동했다가 돌아올 때 다시 로드되지 않습니다. Shell이 페이지의 전체 계층을 소유하기 때문에 그렇게 할 수 있습니다.

또한 Shell을 사용하여 그리기 성능을 최적화하는 방법에 대한 몇 가지 생각이 있습니다. 그리기를 Shell로 제한하지는 않을 것이지만 동일한 패스에서 모든 그리기를 수행할 수 있으므로 Shell을 사용하여 그리기를 훨씬 더 효율적으로 만들 수 있다는 생각이 있습니다. 이 스파이크가 아직 완료되지 않았기 때문에 여기에 소금 알갱이가 필요하지만 종이에는 괜찮아 보입니다.

jassmith 에 2018년 05월 18일

👍8 ❤1

모든 69 댓글

@jassmith ,

이것은 XAML 표준화의 관점에서 볼 때 매우 좋은 아이디어이며 강력한 기능을 제공하지만 이 경로를 따라갈 때는 주의해야 합니다. Xamarin.Forms를 XAML 표준(https://github.com/Microsoft/xaml-standard)으로 이동하려는 전반적인 목표에 확실히 기여할 것입니다. 그러나 VisualStates와 함께 이것이 실제로 얼마나 유용할지에 대한 큰 물음표가 있습니다.

이러한 종류의 영역에서 그래픽 가속을 고려해야 합니다. 그래픽 가속의 부족은 이미 애니메이션과 같은 시스템의 일부에서 문제입니다. 내 생각에 Xamarin.Forms가 벡터 이미징을 렌더링하는 책임을 맡으면 이후에 기본 플랫폼에서 제거되고 GPU 처리에서 CPU 처리로 이동됩니다. 이것은 어떤 경우에는 엄청난 성능 저하가 될 것입니다. 하지 말라는 것이 아니라 처리를 CPU로 옮기지 않고 GPU 수준에서 남겨둘 수 있을지 고민해야 한다. XF 라이브러리의 소비자는 기본 플랫폼에서 실행될 항목과 XF 라이브러리에 의해 렌더링되는 항목을 인식해야 합니다.

네이티브 드로잉과 크로스 플랫폼 드로잉 차이 간의 균형 문제도 있습니다. 텍스트는 중요한 포인트입니다. 텍스트는 모든 플랫폼에서 동일하게 렌더링되어야 합니까? 즉, 모든 플랫폼에서 균일성을 만들기 위해 글꼴 렌더링을 XF로 전달해야 합니까? 아마도. 그러나 그것이 XF의 전체 프로젝트가 되어야 한다고 생각하지 않습니다. 사람들은 무의식적으로 작은 시각적 세부 사항을 감지합니다. 세부 사항은 애니메이션 등에 있을 수 있습니다. 특정 플랫폼의 표준에서 조금만 벗어나도 사용자가 불편할 수 있습니다. 따라서 모든 도면을 균일하게 만드는 것이 반드시 좋은 생각은 아닙니다. Avalonia는 확실히 그 길을 가고 있지만 그것은 완전히 별개의 경우이며 이것이 Avalonia와 Xamarin Forms의 차이점입니다.

또한 기본 형식의 이름을 동일하게 지정하고 XAML 표준과 인라인되도록 UWP 및 WPF와 같은 다른 플랫폼과 최대한 가깝게 정렬되도록 주의해야 합니다.

@davidortinau , 이에 대한 생각이 있습니까?

MelbourneDeveloper 에 2018년 04월 13일

👍2

머티리얼 디자인의 가장 큰 특징 중 하나는 Ripple입니다. 이를 지원할 것으로 예상하십니까?
전반적으로 나는 이것이 환상적이라고 생각합니다!

ChaseFlorell 에 2018년 04월 13일

이 방향이 정말 마음에 듭니다. iOS의 경우 기본 요소(i, > 옵션)를 사용하여 기본 보기 셀을 사용하고 있었지만 사용자 지정 테마를 적용할수록 약간의 기본 셀을 모방하고 유창하고 멋진 보기/작업 테마를 위해 더 많이 가고 있다는 것을 알게 되었습니다. 앱에 대해 일관성이 있지만 세부 사항을 제외하고는 네이티브가 아닙니다. 적절한 기본 렌더링 라이브러리가 사용된다면 GPU는 문제가 되지 않을 것이라고 생각합니다. Skia를 읽으십시오. Flutter를 구동하는 것과 동일한 것입니다.

별개의 문제일 수도 있지만 동시에 SVG를 Forms의 1급 시민으로 만드는 것이 좋을 것입니다. 예를 들어 이미지 버튼을 누를 때 애니메이션 틴팅과 같은 깔끔한 효과를 활성화합니다.

내 의견은 결국 플랫폼의 고유한 특성을 수용하는 이상한 예외를 제외하고 플랫폼 간 일관된 동작으로 프로그래밍하기 쉬운 강력하고 풍부하며 기본적으로 보이는(기본이 아닌!) 컨트롤이 필요하다는 것입니다. 예: Android의 파급 효과.

rogihee 에 2018년 04월 13일

@ChaseFlorell 사실 저는 그렇습니다. 템플릿의 이름을 x:Name한 다음 FindByName을 사용하여 파헤칠 수 있다는 아이디어입니다. 기본 요소가 있으면 다른 것과 마찬가지로 여기에 애니메이션을 적용할 수 있지만 애니메이션 콜백을 가져오는 특별한 방법이 있을 수 있습니다. 나는 아직도 그 정확한 세부 사항을 연구하고 있습니다. Skia가 그림을 그리면 Android에서는 쉽게 60FPS에 도달할 수 있으며 Skia가 없어도 다른 플랫폼에서는 60FPS에 도달할 수 있습니다.

@rogihee SVG는 실제로 배송 형식이 아닙니다. 죄송합니다. / 저는 SVG를 플랫폼 간에 일관되게 렌더링하려는 책임을 지고 싶지 않습니다. 어쨌든 그들은 언제 SVG에 힌트를 추가할 예정입니까...

jassmith 에 2018년 04월 14일

👍1

@jassmith , 이것은 하드웨어 그래픽 가속을 사용합니까?

MelbourneDeveloper 에 2018년 04월 16일

Qt의 QML에서 온다면 이것을 보고 싶습니다. 몇 가지 분명한 내장 컨트롤과 결합하여 많은 정보를 변환할 수 있습니다.

조금 시기상조이거나 다른 문제의 가치가 있을 수 있지만, 이를 기반으로 구축된 컨트롤에 대한 접근성/테스트 가능성 스토리 계획은 무엇입니까?

RichiCoder1 에 2018년 04월 16일

@RichiCoder111y 는 확실히 제대로 해결해야 할 사항입니다. 이상적으로는 Text 요소가 간단한 컨트롤에 필요한 대부분의 속성을 자동으로 설정합니다.

jassmith 에 2018년 04월 17일

이것은 xf 4.0의 기능입니까?

juepiezhongren 에 2018년 04월 18일

3.0 시리즈

jassmith 에 2018년 04월 19일

🎉1

@jassmith 로드맵에 그리기 및 셸에 대한 내용이 없습니다.

juepiezhongren 에 2018년 04월 22일

AFAIK 공개 로드맵에는 완전히 예정되지 않은 항목이 포함되어 있지 않습니다.

jassmith 에 2018년 04월 22일

2018년에 이 모든 미리보기가 될까요?@jassmith

juepiezhongren 에 2018년 04월 24일

@juepiezhongren 우리는 이러한 제안을 하기로 약속하지 않았습니다. 그들은 자신의 장점, 결점 등에 대한 공개 토론을 위해 여기에 제시됩니다.

나는 당신의 관심에서 이러한 사양이 당신에게 흥미로운 것으로 생각합니다. Xamarin.Forms를 사용하여 앱을 빌드할 때 도움이 되는 몇 가지 구체적인 예를 공유해 주시겠습니까? 어떤 문제가 해결된다고 보십니까? 그들이 당신에게 어떤 기회를 열어준다고 보십니까?

공유할 수 있는 실제 사례와 이야기는 이것이 실제 가치를 제공할 수 있음을 검증하는 데 매우 유용합니다.

언제나처럼 원하는 경우 누구든지 저에게 이메일을 보내주십시오. 데이비드. [email protected]

davidortinau 에 2018년 04월 24일

나에게 가장 큰 문제는 잠재 고객과 UX/UI에 제공해야 하는 "우리는 Forms 프레임워크로는 그렇게 할 수 없습니다"라는 대답입니다. 그것은 프레임 워크의 신용을 떨어 뜨리고 고객과 함께 할 수있는 기회가 너무 많습니다.

형식에는 우리가 홍보하는 구성 패러다임이 없습니다. 프로젝트는 UI 프리미티브를 사용하여 UI를 빌드할 수 있습니다. 이것은 탐색, 애니메이션(영웅 애니메이션과 같은 항목 포함), UI 요소 및 제스처에 적용됩니다.

이 제안이 플랫폼 중립적인 구성 UI 프리미티브를 제공할까요?

timahrentlov 에 2018년 04월 24일

🎉2 ❤1

@timahrentlov 우리는 논의를 보고 그 한계가 무엇인지 그리고 그 한계의 이유를 정확히 볼 필요가 있습니다. 그러나 솔직히 나는 감히 그렇게까지 생각하거나 멀리 볼 수 없습니다. Xamarin Forms에서 볼 수 있는 문제는 훨씬 단순한 관점에서 볼 수 있습니다. 여전히 개발 리소스가 매우 제한된 프로젝트로 남아 있습니다. 실제로 충분한 전력과 연료가 없는 상황에서 무엇을 할 수 있는지 논의하는 것은 비현실적이거나 쓸모가 없습니다. 나는 요점이 보이지 않는다. Xamarin은 비밀리에 여전히 OSS 커뮤니티의 일부 개인이 작업을 시작하고 문제를 수정하기를 바라고 있습니까? 오해하지 마세요. 저는 Xamarin이 Xamarin Forms에 투자한 시간과 노력을 존중합니다.

opcodewriter 에 2018년 04월 24일

@davidortinau
크로스 플랫폼은 독특한 시각적 디자인, 독특한 버튼 모양, 독특한 자리 표시자 사라지는 효과 등을 확인하기 어렵습니다. 예를 들어, 약간의 폭발과 함께 mac의 알림이 희미해지면 고객에게 깊은 인상을 주기 쉽습니다. 그날 우리가 wpf를 많이 좋아하는 이유, 제가 언급할 한 가지 이유는 모서리가 있는 육각형 버튼과 같이 고유한 경로를 즐길 수 있는 컨트롤 템플릿 때문입니다. 우리는 xf가 이것을 크로스 플랫폼 클라이언트 개발자에게 가져오기를 원합니다.

juepiezhongren 에 2018년 04월 24일

@juepiezhongren 그런 종류의 UI 사용자 정의를 찾고 있다면 그렇게 할 수 있는 플랫폼 간 프레임워크가 없다고 생각합니다. WPF에 대해: WPF를 모바일과 혼합하는 것은 좋지 않습니다.

opcodewriter 에 2018년 04월 24일

우리 팀도 react native를 사용하고 있습니다. 많은 jers가 많은 기여를 하지만 3개월 후에는 전혀 생산적이지 않다는 결론을 내렸습니다. xf의 경우 버그가 있는 단점이 있지만 기본적으로 견고한 솔루션입니다. eps x.native는 모든 기본 API를 유효하게 만듭니다. 부족한 것은 유비의 외모, 설렘을 안고 있는 최근의 야성뿐이다. 게다가 shell을 사용하면 flutter는 무용지물이 될 것이고, flutter.ios와 같은 것이 없으면 flutter는 네이티브 API와 무한한 고통을 겪는 rn과 같을 것입니다.

juepiezhongren 에 2018년 04월 24일

@opcodewriter
우리는 Skiasharp를 자주 사용하여 특수 제어를 수행하며 성능은 만족합니다.

juepiezhongren 에 2018년 04월 24일

@jassmith 는 webgl을 사용하여 wasm에 materialShell을 이식하는 것을 고려했습니다. Skia의 경우 다운로드하기에는 너무 큽니다.

juepiezhongren 에 2018년 04월 25일

기본 드로잉 API에 대한 타사 라이브러리에 대한 하드 뎁을 원하지 않습니다. \그렇게 할 수 있었다

jassmith 에 2018년 04월 25일

👍2

xamarin.mono 및 wasm의 쉘을 사용하면 모든 알파 제품은 dotnet에 대한 증오가 너무 만연한 중국에서 dotnet 르네상스를 일으킬 것입니다.

juepiezhongren 에 2018년 04월 26일

👍2

@jassmith 이 문제에 대한 좋은 소식이 있습니까?

juepiezhongren 에 2018년 05월 04일

@juepiezhongren에 대해 어떤 뉴스를 찾고 계십니까? 이 시점에서 토론을 호출하기 위해 게시된 사양입니다.

ChaseFlorell 에 2018년 05월 04일

드로우와 쉘이 로드맵@ChaseFlorell 에 언제 포함될지 알고 싶습니다.
유니버설 렌더링은 이미 아발로니아와 플러터에 유효합니다.

juepiezhongren 에 2018년 05월 05일

이에 대한 타임라인은 내 개인 개발 속도에 따라 달라집니다. 여기에서 목표는 전체 팀을 이러한 노력에 산만하게 하는 것이 아니라 저만 참여시키는 것입니다. 쉘 분기를 함께 보고 싶다면 추적할 수 있습니다. Shell은 그림을 그릴 것입니다.

jassmith 에 2018년 05월 06일

🎉1

참고로 저는 수직으로 그림을 그리는 부분을 매우 빨리 세우고 커뮤니티에서 더 빨리 끝내고 싶다면 도움을 요청할 생각입니다.

jassmith 에 2018년 05월 06일

이것은 모두 매우 훌륭하지만 그래픽 가속을 사용합니까?

MelbourneDeveloper 에 2018년 05월 07일

@jassmith on ios, system.draw 사용 Android에서는 skiasharp가 사용됩니다 || 모든 것에 대한 skiasharp?

juepiezhongren 에 2018년 05월 07일

@juepiezhongren 여러 백엔드를 지원하므로 Skia를 사용하려면 Skia를 사용하고 기본 드로잉 API를 사용하려면 대신 Skia를 사용합니다. 기본적으로 기본 백엔드를 사용하고 Skia가 옵트인되어 종속성이 강제되지 않습니다.

jassmith 에 2018년 05월 07일

@jassmith 그것은 system.draw가 안드로이드가 아닌 ios에서 사용 가능하다는 사실에 정말 연결되어 있습니다.

juepiezhongren 에 2018년 05월 07일

@juepiezhongren 이 System.Drawing에 대한 지원을 추가하는 것은 여기에서 제 범위가 아닙니다. 그러나 이 사양에서는 System.Drawing을 사용하지 않습니다.

jassmith 에 2018년 05월 07일

기본적으로 그리기는 렌더링을 훨씬 적게 발생시킵니다.

juepiezhongren 에 2018년 05월 08일

그렇지 않습니다. 드로잉은 드로잉을 렌더링하는 무언가에 의해 뒷받침되어야 합니다. 사용자 정의 렌더러가 덜 필요하다는 것을 의미하지 않는 한 그렇습니다. 동의합니다.

jassmith 에 2018년 05월 08일

나는 "가능한 한 wpf/uwp에 가깝게 하라"는 진영에 속해 있는데, 이것이 항상 여기에서 가장 인기 있는 위치는 아니라는 것을 알고 있습니다.

그러나 이것은 모든 렌더링을 수행하는 프레임워크와 현재 XF 패러다임 사이에서 완전히 보이지 않는 절충안처럼 보입니다.

나는 프리미티브가 각 플랫폼에 대응할 것이라고 가정하고 따라서 하드웨어 가속은 문제가 되지 않을 것입니다. Windows/iOS/Android/etc는 여전히 직사각형, 원, 그라디언트 등을 렌더링하고 있으며 이미 사용하는 것과 동일한 정도로 하드웨어 가속을 사용할 것입니다. 이것은 우리가 컨트롤 디자이너에게 버튼에 대한 Apple의 아이디어와 Microsoft의 아이디어에 얽매이지 않고 프리미티브를 사용하여 컨트롤을 디자인할 수 있는 능력을 제공할 것입니다.

내가 그것을 올바르게 요약합니까?

legistek 에 2018년 05월 17일

🎉2 👍1

@pmorelegistek 기본적으로 예입니다. 그리고 주요 디자인 요소로 블러(Blur)가 포함되어 있지 않기 때문에 머티리얼(Material)을 먼저 처리하고 있습니다. 이것은 우리가 실제로 모든 곳에서 작동하도록 만들 수 있음을 의미합니다(Android를 볼 때).

jassmith 에 2018년 05월 17일

🎉2

Shell v1을 마치면 즉시 여기로 넘어갑니다.

jassmith 에 2018년 05월 17일

@jassmith 황금입니다. UX 디자인에 맞는 기본 컨트롤을 사용하고 필요한 디자인 요소(가급적 소수)에 대해서만 스키와 같은 그려진 컨트롤을 쉽게 추가합니다.

더 이상 "Xamarin Forms에서는 그렇게 할 수 없습니다"라고 디자이너 및 고객과 이야기하지 않아도 됩니다. 이것은 (플러터와 달리) 진정한 네이티브 느낌을 유지하면서 디자인 제한을 제거합니다.

재료 쉘 전에 이것을보고 싶습니다. 이것은 XF의 실질적인 한계를 해결합니다.
Shell은 쉽고 빠르게 시작할 수 있는 n번째 기능입니다. _시작_을 하는 것이 너무 오랫동안 초점이 되어 왔지만 _추가_를 얻기 위한 이와 같은 기능은 XF 개발자를 _유지_할 것입니다.

VincentH-Net 에 2018년 05월 18일

이것은 Material Shell이 이것에 의존하기 때문에 Material Shell보다 먼저 일어나야 합니다. Shell보다 먼저 이것을 보고 싶다고 말씀하신 것 같은데요?

jassmith 에 2018년 05월 18일

👍8 ❤1

@weitzhandler 앞으로 4-6주 안에 이 작업으로 넘어가기를 바랍니다. 이것은 그 쉘을 작동시키는 데 훨씬 빠를 것입니다. 그 시간 중 어느 것도 고정되어 있지 않습니다.

jassmith 에 2018년 05월 21일

timahrentlov 에 2018년 05월 23일

@jassmith https://github.com/nventive/Uno
좋아요.
단일 렌더링은 훌륭합니다

juepiezhongren 에 2018년 05월 26일

form은 급진적 탐험가가 될 것이고 uno는 보수적 탐험가가 될 것입니다.
우리는 둘 다 사랑합니다

juepiezhongren 에 2018년 05월 26일

+1 최대한 빨리 보고 싶은 많은 사용자 정의 UI 문제를 해결할 수 있는 훌륭한 기능

RadwanIbrahim 에 2018년 06월 22일

👍2

@jassmith 는 3.3.0에서 추첨을 할 것 같습니까?

juepiezhongren 에 2018년 07월 09일

❤1

이에 대한 업데이트가 있습니까?

우리에게 이것은 Xamarin이 구현하기를 바라는 가장 강력한 기능입니다.

우리는 주로 LoB 앱을 개발하며, 최우선 순위 중 하나는 개발 속도입니다.
우리는 적절한 작업을 수행하고, 멋지게 렌더링되며, 개발 시간이 덜 걸리는 매력적인 UI가 있는 한 기본 모양과 느낌에 덜 신경을 씁니다.

각 플랫폼에서 각 양식과 페이지를 개별적으로 테스트하고 조정해야 하는 것은 실시간 킬러이며 모든 플랫폼에서 앞뒤로 세 번 확인해야 하는 사소한 UI 변경이 필요합니다.

Shell & Material Shell은 축복이자 기쁜 소식입니다. 앞으로 밀어주세요! 이것은 사용자가 다른 곳(Uno, Flutter 및 기타)을 계속 사용하게 하는 유일한 방법입니다.

weitzhandler 에 2018년 07월 20일

👍1

3.3에서는 추첨이 안 된다는 슬픈 소식

juepiezhongren 에 2018년 07월 24일

👍1

이것에 대한 +1, uwp 배경에서 오는 XF를 정말로 사용하고 싶지만 단점이 있습니다. 현재 저는 플러터를 시도하고 있지만 이것이 가능한 빨리 구현된다면 XF로 확실히 올 것입니다.

touseefbsb 에 2018년 08월 03일

👍1

나는 이것이 훌륭한 기능이라는 데 동의하고 구현해야 합니다. 예를 들어 실선, 점선 등과 같은 선 스타일도 포함할 것입니다.

jrahma 에 2018년 08월 07일

소식이 있나요? 계획? 로드맵?

weitzhandler 에 2018년 09월 06일

👍2

웃기게도, 어젯밤 나는 커스텀 렌더러를 실험하고 있는 나 자신을 발견했고 이 모든 것이 커스텀 뷰로 우리 자신의 프리미티브를 정의하고 그것들을 기반으로 구축함으로써 수행될 수 있다는 거의 결론을 내렸습니다. Border, Ellipse, Line 이상은 필요하지 않습니다.
이것이 공식적으로 지원되는 것을 보고 싶지만 기다리지 않습니다. :)

legistek 에 2018년 09월 06일

👍1

@jassmith
예를 들어 Line 및 Rectangle 가 실제 조회수가 될까요? (예제에는 Ellipse 가 있는 Grid 가 자식 보기로 있기 때문입니다). 할 것이다
탭 이벤트를 처리하기 위해 Rectangle 에 추가 TapGestureRecognizer를 첨부할 수 있습니까?
이것들은 실제 뷰이기 때문에 프리미티브를 그리기 위한 실제 뷰가 있으면 렌더링 속도가 저하되지 않습니까?

andreinitescu 에 2018년 10월 15일

@andreinitescu 나는 의도가 Xamarin Forms 측의 실제 보기를 위한 것이라고 생각하지만 기본적으로 보기로 실현되지는 않습니다.

_드로잉 프리미티브는 단순히 렌더러가 없는 뷰입니다_

따라서 체인( Drawing ? DrawingTemplate ?)의 렌더러는 드로어블 자손을 반복하고 그리는 책임이 있습니다.

나는 이것이 CompressedLayout.IsHeadless 가 설정된 레이아웃에 적용되는 것과 동일한 종류의 제한이 적용된다는 것을 의미한다고 생각합니다(제스처 인식기, 효과 없음, 변환 없음 등).

GalaxiaGuy 에 2018년 10월 16일

@GalaxiaGuy 같은 맥락에서 생각하고 있지만 Grid와 같은 실제 보기와 혼합하기 때문에 약간 혼란스럽습니다. 정말 필요한가요? View에서 파생되는 대신 추상 드로잉 요소 DrawingElement 사용하지 않는 이유는 무엇입니까?

andreinitescu 에 2018년 10월 16일

좋은 직업 그냥 올바른 샘플

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button.Template> --> correct this line
</Button>

minaairsupport 에 2019년 02월 11일

👍1

아마도 4.0에있을 것입니까?

KSemenenko 에 2019년 03월 05일

Drawing 는 대상 플랫폼에 독립적인 그래픽 프리미티브를 사용하여 컨트롤을 구현한다는 점에서 좋습니다. 이전에는 NControl이 있었지만 문제가 있었고(netstandard2.0 이전, SkiaSharp 이전) 업데이트되지 않았습니다.

사양 1. SkiaSharp에서 훨씬 더 완전한 형태로 이미 구현된 기능을 복제하고, 2. 이미 유지 관리할 수 없는 Xamarin.Forms 리포지토리에 들어가는 XAML/바인딩을 통해 불필요한 복잡성 계층을 추가합니다.

더 나은 접근 방식은 SkiaSharp를 기반으로 작은 제어 라이브러리를 만드는 것입니다. 엔컨트롤++

@jassmith @rogihee SVG는 정말 배송 형식이 아닙니다. 죄송합니다. // 저는 SVG를 플랫폼 간에 일관되게 렌더링하려는 책임을 지고 싶지 않습니다.

SkiaSharp는 SVG를 지원합니다.

charlesroddie 에 2019년 05월 10일

👎2 👍1

이것에 대한 소식이 있습니까?

timahrentlov 에 2019년 08월 12일

이것에 대한 소식이 있습니까?

wuxueqicai 에 2019년 09월 18일

또한 이것이 여전히 발생할 가능성이 있는지 궁금합니다. 저는 보기 흉하지 않은 크로스 플랫폼 UI 프레임워크를 원하는 진영에 있으며 이것이 이를 달성하는 가장 좋은 방법인 것 같습니다.

legistek 에 2019년 11월 25일

@legistek SkiaSharp는 보이지 않는 크로스 플랫폼 드로잉에 사용할 수 있습니다. 생각하는 Xamarin.Forms 관련 이점은 무엇입니까?

charlesroddie 에 2019년 11월 25일

UI 프레임워크에는 그리기보다 약간 더 많은 것이 있습니다.

legistek 에 2019년 11월 25일

하지만 이 스레드는 UI 프레임워크가 아닌 그리기 프레임워크에 대해 논의하고 있습니다...

charlesroddie 에 2019년 11월 25일

Xamarin Forms용 그리기 프레임워크에 대해 논의하는 중이라고 생각했습니다.

legistek 에 2019년 11월 25일

SkiaSharp는 Xamarin Forms용 그리기 프레임워크입니다. 다른 .Net UI 플랫폼에서도 작동한다는 사실은 확실히 단점이 아니라 장점입니다.

charlesroddie 에 2019년 11월 25일

그리고 OP에서 말했듯이 SkiaSharp는 개별 플랫폼의 기본 드로잉 엔진이 될 수 있지만 이 제안의 아이디어는 추상화 계층을 추가하고 모든 이점과 함께 XAML을 통해 드로잉을 지원하는 것입니다. 가장 주목할만한 것은 데이터 바인딩입니다. 당신이 불필요한 복잡성이라고 부르는 것을 나는 우아하다고 부릅니다.

legistek 에 2019년 11월 25일

이것은 아직 살아 있고/또는 MAUI로 롤링됩니까?

legistek 에 2020년 05월 20일

👍1

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap 은 Xamarin.Forms 4.7.0에 대한 로드맵에서와 같이 모양, 경로 및 브러시를 나열합니다.

samhouts 에 2020년 05월 21일

❤3

멋진 소식! 감사 해요!

legistek 에 2020년 05월 21일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

<p>Xamarin.Forms 드로잉 사양</p>

Xamarin.Forms 드로잉 사양

테마

간단한 그리기 API 샘플

유형

드로잉 템플릿

그림

보기에서 그리기를 위한 새 API

브러시

솔리드컬러브러시

그라디언트 브러시

GradientStopCollection

GradientStop

드로잉 프리미티브

모양

선

타원

텍스트

직사각형

베지어선

베지어포인트

할 것

문제

모양

브러시

드로잉 템플릿

가장 유용한 댓글

모든 69 댓글

관련 문제