Xamarin은 wpf 렌더러와 ButtonRenderer와 같은 일부 Android 렌더러를 빠르게 구성하며 여기서 "빠른"이 무엇을 의미하는지 알고 있습니다.
이 렌더러가 빠르거나 빠르지 않습니까?
미리 감사드립니다.

@ysmoradi 넵! 이러한 새 렌더러는 빠른 렌더러 패턴을 따릅니다(즉, 기본 보기 주위에 래퍼 보기 없음). Android 및 WPF뿐만 아니라 모든 플랫폼에 대해 이 작업을 수행할 계획입니다.

어떤 경우에도 이전 버전과의 호환성을 유지하려고 하지 마십시오. 이것은 새로운 것입니다. XF와 호환될 필요는 없습니다. 당신은 더 나은 것을 만들 수 있습니다.

Skia 그래픽 라이브러리로 렌더링되는 C#으로 완전히 작성된 매핑 및 동작 논리 없이 자체 컨트롤 세트로 UI 프레임워크를 만들지 않는 이유는 무엇입니까? 사람들이 강력하게 사용자 정의된 디자인을 사용하기 때문에 플랫폼 디자인 지침을 일치시키려고 할 필요가 없습니다. 유일한 필요는 유연한 사용자 정의의 가능성입니다. 누락된 부분이 있으면 수정해 주세요. 하지만 왜 렌더러 아키텍처보다 이점이 더 많은지 이해가 되지 않습니다.

이 접근 방식을 사용하면 플랫폼별 렌더러 대신 플랫폼 간 렌더러를 작성할 수 있습니까? Skia-sharp 컨트롤을 사용하여 Button 컨트롤을 매핑하는 것과 같습니다.

플랫폼 렌더러는 잘못된 디자인입니다. 보시다시피 플랫폼 제한으로 인해 UWP를 지원하지 않는 xamarin 제어 라이브러리가 많이 있습니다.
UWP의 그림자를 예로 들어 보겠습니다. 모서리 버튼에서 모서리 그림자를 얻을 수 없습니다(물론 버튼 템플릿을 변경하여 이를 수행할 수 있지만 이는 다른 문제입니다).

크로스 플랫폼 렌더를 구축하는 것이 매우 어렵다는 것을 알고 있습니다. 그러나 flutter는 이것이 가능하다고 말했습니다. 장기적으로 크로스 플랫폼 렌더러가 최상의 솔루션입니다.

전체 앱을 사용자 지정 2D 캔버스로 렌더링하는 것이 모바일 앱에서 원활하게 작동할 수 있다고 생각합니다.

그러나 드래그 드롭, 텍스트 선택, 텍스트 조작을 위한 키보드 단축키 등과 같이 다시 구현해야 하는 사용자 작업이 너무 많기 때문에 데스크톱 앱이나 복잡한 앱에서는 작동하지 않을 수 있습니다.

Skia 그래픽 라이브러리로 렌더링되는 C#으로 완전히 작성된 매핑 및 동작 논리 없이 자체 컨트롤 세트로 UI 프레임워크를 만들지 않는 이유는 무엇입니까? 사람들이 강력하게 사용자 정의된 디자인을 사용하기 때문에 플랫폼 디자인 지침을 일치시키려고 할 필요가 없습니다. 유일한 필요는 유연한 사용자 정의의 가능성입니다. 누락된 부분이 있으면 수정해 주세요. 하지만 왜 렌더러 아키텍처보다 이점이 더 많은지 이해가 되지 않습니다.

전체 앱을 사용자 지정 2D 캔버스로 렌더링하는 것이 모바일 앱에서 원활하게 작동할 수 있다고 생각합니다.

그러나 드래그 드롭, 텍스트 선택, 텍스트 조작을 위한 키보드 단축키 등과 같이 다시 구현해야 하는 사용자 작업이 너무 많기 때문에 데스크톱 앱이나 복잡한 앱에서는 작동하지 않을 수 있습니다.

Skia 그래픽 라이브러리로 렌더링되는 C#으로 완전히 작성된 매핑 및 동작 논리 없이 자체 컨트롤 세트로 UI 프레임워크를 만들지 않는 이유는 무엇입니까? 사람들이 강력하게 사용자 정의된 디자인을 사용하기 때문에 플랫폼 디자인 지침을 일치시키려고 할 필요가 없습니다. 유일한 필요는 유연한 사용자 정의의 가능성입니다. 누락된 부분이 있으면 수정해 주세요. 하지만 왜 렌더러 아키텍처보다 이점이 더 많은지 이해가 되지 않습니다.

당신은 이 모든 것에 대해 절대적으로 옳습니다. 하지만 팀이 단 하나의 접근 방식을 선택하도록 강요받는 것은 아닙니다. 시간이 부족해서 그런 것 같아요. 내 말은 그들이 .net 6과 함께 "완전히 새로운" 완전한 크로스 플랫폼 UI 프레임워크를 1년 안에 출시해야 한다는 뜻입니다. 그리고 오래 동안 테스트를 거친 좋은 프레임워크를 기반으로 하는 것이 훨씬 덜 위험합니다. 괜찮고 그래야 합니다. 그러나 저는 장기적으로 커스텀 2D 캔버스 렌더링이 훨씬 더 많은 이점을 가지고 있으며 "크로스 플랫폼"이라고 부를 가치가 있다고 믿습니다. Xamarin 양식은 정말 좋은 기능이며 오늘날 엄청난 발전을 이루고 있습니다. 하지만 계속해야 할 때입니다. Microsoft와 xamarin 팀은 매우 영리한 엔지니어를 보유하고 있으며 이러한 접근 방식을 고려하거나 http://avaloniaui.net/ 을 비장의 카드로 사용할 수도 있습니다.

Skia 그래픽 라이브러리로 렌더링되는 C#으로 완전히 작성된 매핑 및 동작 논리 없이 자체 컨트롤 세트로 UI 프레임워크를 만들지 않는 이유는 무엇입니까? 사람들이 강력하게 사용자 정의된 디자인을 사용하기 때문에 플랫폼 디자인 지침을 일치시키려고 할 필요가 없습니다. 유일한 필요는 유연한 사용자 정의의 가능성입니다. 누락된 부분이 있으면 수정해 주세요. 하지만 왜 렌더러 아키텍처보다 이점이 더 많은지 이해가 되지 않습니다.

Skia 개발자가 100% 변경하여 풍부한 디자인을 제공할 수 있도록 4차 렌더 기본 회색을 사용하면 멋질 수 있습니다.
백콤 가능성을 위해 3개는 그대로 두지만 "개발자에게 직접 그리십시오"_skia_render를 추가하고 개발자에 대한 90%의 책임을 집니다.

렌더러의 개념이 유지되어야 한다면 INotifyPropertyChanged 및 이벤트 핸들러를 통해 공유 UI 코드와 렌더러 사이의 다리를 제거하는 것을 생각할 수 있습니까? 즉

• 공유 컨트롤에 _property_를 설정하고 PropertyChanged 이벤트가 전파되는 대신 플랫폼 렌더러에서 직접 속성을 매핑하고 설정할
• 공유 컨트롤에서 _method_를 호출하고 이벤트가 발생하고 렌더러가 처리하는 대신 메서드를 플랫폼 렌더러에서 직접 매핑하고 관련시킬 수 있습니까?

INotifyPropertyChanged 는 MVVM 디자인 및 느슨하게 결합된 뷰 모델에 적합하지만 공유 UI 코드와 플랫폼 렌더러 사이의 브리지 메커니즘으로 항상 투박하게 느껴졌습니다. 이는 결과적으로 더 나은 성능, 공유 UI와 렌더러 레이어 간의 '수다' 감소, 더 나은 개발자 경험으로 이어집니다.

이것은 길지만 마우이의 "야구 내부"를 볼 가치가 있습니다.
https://www.youtube.com/watch?v=_MGh3xipWm4

마우이의 아키텍처는 플랫폼에서 렌더링된 컨트롤과 캔버스로 그린 컨트롤을 모두 지원할 것이며, 더 나아가 고귀한 @Clancey 는 MVU 플레이버에서만 작동하는 것이 아닌 마우이용 스키 기반 렌더 세트에서 계속 작업할 것입니다. 마우이 뿐만 아니라 MVVM 패턴에도 적용됩니다.

언뜻 보기에 Maui는 Forms의 브랜드 변경처럼 보이지만 자세히 살펴보면 레이어를 더 느슨하게 결합하여 이 스레드에서 우리가 요청하는 많은 것을 지원하도록 Forms 아키텍처를 재구성한 것입니다. 앞으로 즐거운 시간.

이것은 주제에서 약간 벗어나지만 이 정확한 것과 관련이 있기 때문에 묻고 싶은 것입니다.

SKCanvasView (또는 일반적으로 Skia)에서 메모리는 어떻게 작동합니까? 각각은 항상 크기에 비례하여 메모리를 차지합니까? 다른 항목과 겹치면 변경됩니까?

예를 들어 그라디언트 컨트롤(Skia로 작성된 렌더러)이 있고 그 위에 반투명 버튼(Skia로 작성된 렌더러)이 있는 경우 두 배의 메모리를 차지하거나 그래픽 컨텍스트가 어떻게든 공유됩니까? Skia 컨트롤이 Skia 이외의 컨트롤과 겹치면 어떻습니까?

이전에 Skia를 사용하여 Forms에서 멋진 그래픽 컨트롤을 구현하는 것을 고려했지만 메모리 작동 방식을 이해하지 못하는 것이 항상 걱정거리가 되었습니다.

@GalaxiaGuy wpf 컨트롤에서 호스팅되는 winform 컨트롤과 마찬가지로 스키어 컨트롤이 아닌 컨트롤에서 겹친 스키어 컨트롤을 사용하는 것 같습니다. 당신은 이것을 할 수 있지만 최선은 아닙니다.
SKCanvasView 렌더링된 두 개의 컨트롤이 있는 경우 그래픽 컨텍스트는 공유되지 않습니다. 가장 좋은 방법은 렌더링된 두 개를 합성하여 단일 캔버스에 그리는 것입니다.
내 테스트에서 SkiaSharp 성능은 정적 작업만 하면 그렇게 나쁘지 않습니다. 그리고 몇 가지 애니메이션을 하려고 하면 내 랩톱에서 CPU 사용량이 약간 높습니다.

많은 사람들이 Skia에 열광하는 이유는 무엇입니까? 좋은 렌더링 사양은 낮은 수준에서 사용되는 렌더링 엔진과 무관합니다. 특정 플랫폼 렌더러가 Skia(또는 Direct2D 또는 OpenGL 등)를 사용하려는 경우 응용 프로그램 계층에서 걱정해야 할 사항이 되어서는 안 됩니다.

몇 년 전 WPF를 사용한 XAML의 가장 큰 약속은 Lookless Controls 의 아이디어였습니다. Xamarin Forms는 이 기능 없이 XAML을 사용했으며 이것이 가장 취약한 지점이었습니다. 몇 년 후 Drawing 사양으로 부분적으로 수정되었습니다.
다양한 OS 및 프레임워크의 기존 구성 요소에 대한 또 다른 인터페이스 및 추상화 집합이 필요하다고 생각하지 않지만 플랫폼에 구애받지 않는 시각적 기본 요소 및 플랫폼별 그래픽 렌더링 백엔드로 템플릿 화 된 XAML 기반의 진정으로

몇 년 전 WPF를 사용한 XAML의 가장 큰 약속은 컨트롤의 실제 그래픽이 템플릿으로 연기되는 Lookless Controls의 아이디어였습니다. Xamarin Forms는 이 기능 없이 XAML을 사용했으며 이것이 가장 취약한 지점이었습니다. 몇 년 후 Drawing 사양으로 부분적으로 수정되었습니다.

동의! 그리고 앱이 필요로 하는 모든 것의 99%를 달성하려면 정말 적은 수의 렌더링 기본 요소가 필요합니다.

• 테두리(그림자 및 둥근 모서리 옵션 포함)
• 선/타원/사각형
• 일반 텍스트 렌더링
• 일반 텍스트 입력
• 서식 있는 텍스트 렌더링
• 서식 있는 텍스트 입력
• HTML 렌더링
• 이미지 발표자
• 오디오/비디오 발표자
• 단색 및 선형/방사형 그라데이션 브러시

XF 렌더링 플랫폼은 프레임워크에 새로운 유형의 컨트롤이 추가될 때마다 프레임워크 내의 기존 프리미티브를 기반으로 빌드하는 대신 새 렌더러로 수행되기 때문에 너무 비대해졌습니다.

예, 훨씬 더 많은 논리를 프레임워크 계층으로 이동해야 하며, 항목 제어와 관련하여 가장 어려운 점입니다( VirtualizingStackPanel 는 확장 가능한 항목 뷰어를 갖는 데 중요하지만 내가 아는 한 외부로 효과적으로 이식된 적이 없는 것으로 알고 있습니다. WPF가 너무 복잡하기 때문에). 그러나 WPF가 오픈 소스이기 때문에 많은 것들이 지금 MAUI로 포팅될 수 있으며 마침내 이것이 일어나기 시작해야 할 때라고 생각합니다.

앱이 필요로 하는 모든 것의 아마 99%를 달성하려면 아주 적은 수의 렌더링 프리미티브가 정말로 필요합니다.

Uno 플랫폼은 이 접근 방식을 사용하고 있습니다.

@velocitysystems

공유 컨트롤에 속성을 설정하고 PropertyChanged 이벤트가 전파되는 대신 플랫폼 렌더러에서 속성을 직접 매핑하고 설정할 수 있습니까?

이것이 이번 변화의 큰 목표이기도 합니다. 이러한 변경 사항의 반대편에 있으면 렌더러는 BindableObject 또는 INPC가 무엇을 의미하는지 전혀 모릅니다.

이것이 이번 변화의 큰 목표이기도 합니다. 이러한 변경 사항의 반대편에 있으면 렌더러는 BindableObject 또는 INPC가 무엇을 의미하는지 전혀 모릅니다.

렌더러의 방법은 때마다 프레임 워크에 의해 호출 얻을 것이다 그래서 BindableProperty 값 대신에 가입해야하는 렌더러의 변경 PropertyChanged ?

@legistek 맞아

이것은 기본적으로 종속성을 반전시킵니다.

따라서 렌더러는 IButton에 대해서만 작동합니다.

그런 다음 System.Maui는 렌더러가 Xamarin.Forms.Core에 대한 참조를 갖는 방식과 반대되는 렌더러 프로젝트에 대한 참조를 추가합니다.

나는 우리가 여기에있는 스파이크를 확인했습니다
https://github.com/dotnet/maui/pull/66

그래서 당신은 이것이 어떻게 생겼는지 볼 수 있습니다

저는 오늘 오후 3시 30분 PDT 시간에 @davidortinau 와 함께

https://www.twitch.tv/microsoftdeveloper

우리와 함께! 확인 해봐! 그리고 질문하세요!

@PureWeen 불행히도 나는 그것을 놓쳤다. YouTube에서 사용할 수 있는 녹음이 있습니까?

이것이 이번 변화의 큰 목표이기도 합니다. 이러한 변경의 반대편에 있으면 렌더러는 BindableObject 또는 INPC가 무엇을 의미하는지 전혀 알지 못합니다.

그것은 거대하고 실질적인 개선입니다. 의심할 여지 없이 마우이로의 이동과 함께 많은 렌더러에서 사용되는 복잡한 상속 모델이 제거되어 보다 구성적인 접근 방식을 선호하게 될 것입니다.

오늘은 #66을 리뷰합니다.

#66을 보면 리플렉션을 사용하는 대신 'bait-and-switch'로 슬림 렌더러가 빌드되고 호출되는 것을 볼 수 있습니다. 몇 가지 생각:

• Slim 렌더러가 GC 문제, 특히 관리 및 기본 제어 수명 주기 간에 불일치가 있는 Android에서 해결할 수 있습니까? 이것은 ObjectDisposedException 이어지는 가상화된 레이아웃의 자식 보기에서 특히 두드러집니다.
• Slim 렌더러가 Effect 의 사용 중단으로 이어집니까? 효과는 유용할 수 있지만 궁극적으로 레이아웃 수명 주기에 복잡성과 대기 시간의 또 다른 가능성을 추가합니다.
• '양방향' 속성은 새로운 렌더러 디자인에서 어떻게 작동합니까? 예를 들어 MediaElement 에 Position( TimeSpan ) 속성이 있다고 가정해 보겠습니다. Setter는 현재 위치를 업데이트하고 getter는 기본 미디어 플레이어(예: AVPlayer , MediaPlayer 에서 현재 위치를 검색합니다. 슬림 렌더러로 _getter_를 매핑하기 위한 디자인이 있습니까?

Slim 렌더러가 GC 문제, 특히 관리 및 기본 제어 수명 주기 간에 불일치가 있는 Android에서 해결할 수 있습니까? 이것은 두려운 ObjectDisposedException으로 이어지는 가상화된 레이아웃의 자식 보기에서 특히 두드러집니다.

우리는 여기에 몇 가지 아이디어가 있습니다!! 우리는 ODE 예외의 전부는 아닐지라도 대부분을 희망적으로 해결하기 위해 폐기 전략을 약간 재작업하기를 원합니다. 지금 우리는 Android/iOS의 모든 것을 매우 적극적으로 폐기하지만 GC가 하는 일을 하기 위해 GC에 의존할 수 있다고 확신합니다. 모든 것을 역참조하고 GC가 이러한 많은 경우에 도움이 되는 작업을 수행하도록 하면

Slim 렌더러는 Effect의 사용 중단으로 이어집니까? 효과는 유용할 수 있지만 궁극적으로 레이아웃 수명 주기에 복잡성과 대기 시간의 또 다른 가능성을 추가합니다.

이것은 우리가 이 아이디어를 발전시킬 때 살펴봐야 할 좋은 점입니다. 이 모든 것에 대한 최종 디자인에 도달하면 효과를 살펴보겠습니다. 그러나 예, 효과가 전체 렌더러로 전환하지 않고도 기본 요소를 활용하기 위한 방법으로 의도된 대로 사용되지 않는 것을 볼 수 있습니다. 매퍼는 기본적으로 쓸모없는 효과

'양방향' 속성은 새로운 렌더러 디자인에서 어떻게 작동합니까? 예를 들어 위치(TimeSpan) 속성이 있는 MediaElement가 있다고 가정해 보겠습니다. Setter는 현재 위치를 업데이트하고 getter는 기본 미디어 플레이어(예: AVPlayer, MediaPlayer)에서 현재 위치를 검색합니다. 슬림 렌더러로 게터를 매핑하기 위한 디자인이 있습니까?

우리는 아직 이 문제를 조금 해결하고 있습니다. @Clancey가 틀렸다면 정정해 주세요. 하지만 ActionMapper는 이에 대한 우리의 현재 접근 방식이었습니다. 예? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

'양방향' 속성은 새로운 렌더러 디자인에서 어떻게 작동합니까? 예를 들어 위치(TimeSpan) 속성이 있는 MediaElement가 있다고 가정해 보겠습니다. Setter는 현재 위치를 업데이트하고 getter는 기본 미디어 플레이어(예: AVPlayer, MediaPlayer)에서 현재 위치를 검색합니다. 슬림 렌더러로 게터를 매핑하기 위한 디자인이 있습니까?

우리는 아직 이 문제를 조금 해결하고 있습니다. @Clancey가 틀렸다면 정정해 주세요. 하지만 ActionMapper는 이에 대한 우리의 현재 접근 방식이었습니다. 예? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

정확히. 따라서 ActionMapper는 SetElement 단계에서 호출되지 않는다는 점을 제외하고 PropertyMapper와 동일합니다. 따라서 WebView, GoBack과 같은 경우. 초기화 중에 호출하고 싶지는 않지만 여전히 렌더러와 통신해야 하는 것입니다.

우리는 이미 양방향 매핑을 지원합니다. 즉 엔트리. 텍스트 값이 항목에 있을 때. IEntry에는 string Text {get;set;} 가 있으며 값을 설정하기만 하면 됩니다. 따라서 미디어 요소의 경우 2가지 옵션이 있습니다. 하나는 단순히 위치/시간이 변경될 때 다시 설정하는 것입니다. 당신이 그것을 대신 쿼리하는 것으로 만들고 싶다면. 그렇게 할 수 있습니다. xplat 보기는 렌더러에 액세스할 수 있습니다. view.Renderer.NativeView as NativeMediaView 이제 원하는 속성을 가져올 수 있습니다!

다음은 빌드 중 스트림의 일부 비디오입니다.

@Clancey 는 여기에서 더 자세히 설명하겠습니다.
https://www.youtube.com/watch?v=_MGh3xipWm4

나는 David와 함께 여기에서 그것들을 약간 만진다.
https://www.youtube.com/watch?v=lAmwjfZY1IM

'양방향' 속성은 새로운 렌더러 디자인에서 어떻게 작동합니까? 예를 들어 위치(TimeSpan) 속성이 있는 MediaElement가 있다고 가정해 보겠습니다. Setter는 현재 위치를 업데이트하고 getter는 기본 미디어 플레이어(예: AVPlayer, MediaPlayer)에서 현재 위치를 검색합니다. 슬림 렌더러로 게터를 매핑하기 위한 디자인이 있습니까?

우리는 아직 이 문제를 조금 해결하고 있습니다. @Clancey가 틀렸다면 정정해 주세요. 하지만 ActionMapper는 이에 대한 우리의 현재 접근 방식이었습니다. 예? https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

정확히. 따라서 ActionMapper는 SetElement 단계에서 호출되지 않는다는 점을 제외하고 PropertyMapper와 동일합니다. 따라서 WebView, GoBack과 같은 경우. 초기화 중에 호출하고 싶지는 않지만 여전히 렌더러와 통신해야 하는 것입니다.

우리는 이미 양방향 매핑을 지원합니다. 즉 엔트리. 텍스트 값이 항목에 있을 때. IEntry에는 string Text {get;set;} 가 있으며 값을 설정하기만 하면 됩니다. 따라서 미디어 요소의 경우 2가지 옵션이 있습니다. 하나는 단순히 위치/시간이 변경될 때 다시 설정하는 것입니다. 당신이 그것을 대신 쿼리하는 것으로 만들고 싶다면. 그렇게 할 수 있습니다. xplat 보기는 렌더러에 액세스할 수 있습니다. view.Renderer.NativeView as NativeMediaView 이제 원하는 속성을 가져올 수 있습니다!

여기서 고려해야 할 또 다른 사항은 C#9에서 제공되는 레코드입니다. 특수성은 변경할 수 없으며 init 속성 접근자가 있다는 것입니다. 따라서 양방향 바인딩에서 사용할 수 있도록 하려면 매퍼가 with 연산자를 사용하여 새 인스턴스를 반환할 수 있어야 합니다.

뷰가 레코드에 바인딩될 수 있기를 진심으로 바랍니다. 이렇게 하면 순수 MVVM 또는 순수 MVU의 경우 훨씬 더 쉬워지기 때문입니다.

질문: 귀하가 게시한 다이어그램에는 Windows.UI.* 의해 렌더링되는 Windows 컨트롤이 있지만 제가 이해하는 바와 같이 이는 현재 사용되지 않으며 업데이트가 표시되지 않습니다. 유창한 디자인 렌더링에 대한 모든 개선 사항은 WinUI 프로젝트의 일부로 Microsoft.UI.* 에서 진행됩니다. 이에 대한 의견을 말씀해 주시겠습니까?

네이티브 컨트롤에 매핑하는 것은 큰 실수라고 생각합니다. 이것은 Xamarin.Forms의 끔찍한 부분입니다. 독특하고 아름다운 레이아웃을 쉽게 만들 수 없습니다. 렌더링을 사용하여 모양 없이 WPF 및 Flutter 컨트롤의 개념과 접근 방식을 따라야 했습니다. OpenGL / DirectX / Metal을 사용하여 C ++로 작성된 엔진은 지속적으로 변화하는 플랫폼 구조에 의존하지 않을 뿐만 아니라 이식성, 성능 및 유연성을 용이하게 합니다.

이 문제는 새로운 아키텍처/속성 매퍼에 대해 이야기하는 것입니다. 매핑 대상이 아닙니다. 다시 한 번 말씀드립니다. 네이티브를 위한 슬림 렌더 아키텍처는 우리가 그린 컨트롤 접근 방식을 절대 하지 않을 것이라는 의미가 아닙니다. 그러나 이것은 우리가 네이티브 대 비네이티브 컨트롤을 혼합하여 일치시킬 수 있게 해주며, 순수하게 그려지면 더 어렵습니다. 드로잉 레이어를 포함하여 동일한 슬림 렌더러 아키텍처를 따르는 Skia 기반 컨트롤에 대한 작업을 계속할 계획입니다. https://github.com/Clancey/Comet/tree/dev/src/Comet.Skia/Handlers.

이 렌더러에 대한 나의 2¢(내가 완전히 이해하지 못한다는 것을 인정합니다, TBH):

동일한 컨트롤 클래스를 사용하여 플랫폼에서 렌더링된 컨트롤(예: UIButton 래핑)과 겉보기 없는 컨트롤(WPF로 표시)을 모두 구현할 수 있는 방법에 대한 아이디어가 있었습니다. 솔직히 말해서 매우 간단합니다. Maui Button 클래스가 컨트롤 템플릿을 사용하도록 하고 여기에서 모든 플랫폼별 렌더러 코드를 제거합니다. 그런 다음 ButtonRenderer가 포함된 Button에 대한 기본 템플릿을 제공합니다. ButtonRenderer는 각 UI 툴킷에 대한 플랫폼별 코드를 사용하여 Cocoa/UIKit/UWP/etc와 통신하고 앱 개발자가 사용하는 Button 클래스는 단순히 속성을 전달합니다. 사용자가 사용자 정의 그린 버튼을 사용하려는 경우 WPF에서와 마찬가지로 ButtonRenderer 대신 템플릿을 재정의하고 드로잉 클래스(어떤 모양이든지 간에)를 사용할 수 있습니다. WPF를 이해하는 것만큼 Xamarin.Forms를 이해하는 데 시간을 들이지 않았기 때문에 이것이 오늘날 마우이에서 이미 가능한지(또는 이미 사용 중인지) 솔직히 모르겠습니다.

네가 생각하는 것을 말해줘!

슬림 렌더러가 다른 앱 모델(MVVM, MVU 등)에 대해 의미하는 바를 이해하려고 합니다.

초기 다이어그램은 각기 다른 앱 모델에 자체 렌더러 세트가 있음을 알려 주는 것 같습니다.
그러나 제 생각에는 렌더링 유형(예: XF와 같은 기본 컨트롤으로 렌더링, 캔버스로 렌더링 등)당 하나의 렌더러 세트가 있는 것이 좋습니다.
렌더러는 앱 모델을 인식할 필요가 없으며 기본 컨트롤에 올바른 업데이트를 적용할 수 있도록 어떤 값이 어떤 속성에 매핑되는지만 알면 됩니다.
IButton 각 앱 모델에 대해 다르게 구현되며 해당 렌더러의 매핑된 기능을 호출합니다.

Fabulous와 같은 타사 라이브러리에는 각 플랫폼의 각 컨트롤에 대한 모든 적절한 렌더러를 구현하는(모든 버그와 함께) Microsoft의 인력이 없기 때문에 이것은 중요합니다.

또 다른 요점은 제어 인터페이스( IButton )가 렌더러에서 사용하려면 getter 전용이어야 한다는 것입니다.
렌더러는 값을 설정하지 않으며 각 앱 모델은 컨트롤을 다르게 형성합니다(BindableProperty, BindingObject 등).
예를 들어 Fabulous는 변경할 수 없는 뷰를 갖습니다. 내부적으로만 IButton 의 인스턴스로 변형을 설정할 수 있습니다.

그런 식으로 Fabulous는 IButton 인터페이스를 내부 사전을 통해 독자 보기로 직접 사용할 수 있으므로 렌더러가 작동할 수 있습니다.

// This is the type used by our users, sort of a Builder that return a new instance each time
// and append the set value to an internal list 
public struct Button
{
     public Button Text(string value) => (...);

     internal ReadOnlyDictionary<string, obj> Build() { ... }
}

// This will be an implementation of IButton, hidden from our users
internal class FabulousButton : IButton
{
    private ReadOnlyDictionary<string, obj> _properties;
    FabulousButton(ReadOnlyDictionary<string, obj> properties)
    {
        _properties = properties;
    }

    void Update(ReadOnlyDictionary<string, obj> properties)
    {
        var previousProperties = _properties;
        _properties = properties;

        // Diffing of the 2 dictionaries to determine what changed
        // and which mapped functions inside the renderer should be called
        (...)
    }

    public string Text => _properties["Text"];
}

@TimLariviere 당신이 말한 모든 것이 작동 방식입니다 :-)

거기에 있는 그림은 렌더러만큼 혼란스럽습니다.

이것에서 당신이 걱정해야 할 유일한 부분은 Fabulous Button이고 거기에서 우리가 처리할 다른 모든 것입니다.

대부분의 인터페이스는 읽기 전용입니다.

버튼이 사용하는 인터페이스입니다.
https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Views/IText.cs

(렌더러에 관한 한) 실제로 당신에게 달려 있는 것은 IButton을 다시 소비해야 한다는 신호를 렌더러에 보내는 것입니다.

예를 들어, 이 모든 것의 BindableObject 버전에서 우리는 여기에서 Renderer의 updateproperty 메소드를 호출하고 있습니다.

https://github.com/dotnet/maui/blob/slim-renderer-samples/System.Maui.Core/VisualElement.cs#L1132

(곧?) @Clancey 는 Comet의 공개 버전을 것이므로 그가 어떻게 하는지 볼 수 있습니다.

나는 체크 아웃 할 것이다
https://github.com/dotnet/maui/blob/slim-renderer-samples

여기에 Fabulous.Core 헤드를 추가한 다음 인터페이스에 구현 추가를 시작할 수 있습니다.

@PureWeen 오

@PureWeen @Clancey 마우이 팀이 이 모든 것을 다룰 것이라고 확신하지만 새로운 Slim 렌더러는 상속보다 구성을 선호할 수 있습니다. 상속은 유용하지만 불행히도 XF에서는 일부 렌더러 계층 구조를 매우 복잡하고 유지 관리하기 어렵게 만들었습니다.

@PureWeen
이 URL
https://github.com/dotnet/maui/blob/slim-renderer-samples

404를 제공합니다. 비공개입니까?

@랜덤

https://github.com/dotnet/maui/tree/slim-renderer-samples

@velocitysystems

나는 Maui 팀이 이 모든 것을 다룰 것이라고 확신하지만 새로운 Slim 렌더러는 상속보다 구성을 선호할 수 있습니다. 상속은 유용하지만 불행히도 XF에서는 일부 렌더러 계층 구조를 매우 복잡하고 유지 관리하기 어렵게 만들었습니다.

그것이 그들이 만들어지는 방식입니다. System.Object 에서 직접 상속하는 매우 얇은 기본 클래스가 있습니다.

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.Android.cs

그리고 네이티브 인맥이 없습니다.

거기에서 모든 것은 기본적으로 사전을 통해 정의됩니다.

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.cs#L31

기본적으로 데코레이터처럼 작동합니다.

추가 매퍼로 매퍼를 장식할 수 있으며 자신의 func 등을 주입할 수 있습니다.

우리는 사용자 시나리오의 95%가 매퍼에 고유한 Func를 추가하거나 모두 다중 대상이 될 것이기 때문에 기본 요소에 직접 액세스하는 것을 목표로 합니다.

@PureWeen 샘플에서 이러한 슬림 렌더러의 구현을 논의하는 데 가장 적절한 채널은 무엇입니까?

다음과 같은 질문이 있습니다.

• 기본값은 중앙 집중식으로 정의됩니까? XF에서는 현재 BindableProperty 필드를 생성할 때 정의되지만 앱 모델에 따라 표시되지 않습니다.
• Application 클래스도 (부분적으로) 인터페이스가 됩니까? 많은 UI 동작(리소스, 메뉴, 메인 페이지)을 정의하고 다르게 구현하는 것이 좋습니다.
• 측정/정렬/등이 제어 인터페이스에서 추출됩니까? 앱 모델이 이를 다르게 구현하는 것은 정말 의미가 없다고 생각합니다.

기본값은 중앙 집중식으로 정의됩니까? XF에서는 현재 BindableProperty 필드를 생성할 때 정의되지만 앱 모델에 따라 표시되지 않습니다.

좋은 질문입니다. @클랜시 ? 우리가 이것을 아직 정의했는지 확실하지 않습니다. 모든 매퍼가 속성의 현재 값(기본값)으로 호출되는 초기 설정 단계가 있지만 아직 기본값에 대한 계획이 있는지, 어떻게 일반화할지 잘 모르겠습니다.

Application 클래스도 (부분적으로) 인터페이스가 됩니까? 많은 UI 동작(리소스, 메뉴, 메인 페이지)을 정의하고 다르게 구현하는 것이 좋습니다.

예! 우리는 모든 애플리케이션 클래스(네이티브 및 xplat)를 단일 애플리케이션 클래스로 축소하기를 희망합니다. 이걸 왜 물어보는거야? 귀하의 사용 사례가 궁금합니다.

측정/정렬/등이 제어 인터페이스에서 추출됩니까? 앱 모델이 이를 다르게 구현하는 것은 정말 의미가 없다고 생각합니다.

이 시점에서 그것이 계획입니다. 아이디어는 모든 레이아웃 코드를 추출하여 BindableObject/Property에 의존하지 않도록 하는 것입니다. 이 방법으로 Blazor/Comet/other는 StackLayout을 사용할 수 있고 결과는 동일합니다.

이걸 왜 물어보는거야? 귀하의 사용 사례가 궁금합니다.

나는 아직 내가 무엇을 원하는지 완전히 확신하지 못합니다. 그러나 Fabulous에서는 현재 글로벌 스타일과 메인 메뉴(macOS와 같은)를 정의하는 데 좋은 스토리가 없습니다. 사용자가 Application 클래스를 스스로 서브클래스화할 수 있도록 했기 때문에 기본적으로 클래식 Xamarin.Forms에서와 같이 리소스/메뉴를 정의하도록 지시합니다.

따라서 이상적으로는 Application의 모든 UI 관련 속성도 보기의 일부가 되므로 보기 구분 논리도 적용할 수 있습니다.

그런 것

public interface IAppRoot
{
    IEnumerable<object> Resources { get; }
    IMenu MainMenu { get; }
    IPage MainPage { get; }
}

public class Application
{
    /// Bootstrapping and other logic of MAUI

   public IAppRoot Root { get; set; } // Replaces MainPage, which is typed for pages only
}

@PureWeen 또 다른 질문: TextChanged , Toggled 등과 같은 이벤트를 트리거하는 책임은 누구에게 있습니까? 컨트롤 또는 렌더러?

다른 앱 모델의 구현을 크게 단순화할 수 있다고 생각하는 한 가지는 변경이 프로그래밍 방식일 때 상태 변경 이벤트를 트리거하지 않을 가능성입니다.

예를 들어, 오늘 TextChanged on Entry는 사용자가 무언가를 쓸 때나 MyEntry.Text = "New value"; 할 때 모두 트리거됩니다.
프로그래밍 방식의 변경에 반응하는 것은 실제로 유용하지 않으며 코드에 대해 추론하는 데 좋지 않은 암시적이라고 생각합니다.

또한 플랫폼이 약간의 지연으로 이벤트를 트리거하고 Fabulous가 돌아올 가능성 없이 동기화되지 않도록 강제하기 때문에 Android에서 무한 루프가 발생합니다.
우리가 찾은 유일한 해결 방법은 값을 설정하기 전에 먼저 이벤트를 구독 취소한 다음 다시 구독하는 것입니다...

궁금한 질문입니다. MAUI가 아키텍처에 구애받지 않는 경우 컨트롤 이름이 아키텍처 이름으로 지정되는 이유는 무엇입니까? 예를 들어 위의 다이어그램에는 Maui가 있습니다. Mvvm .ButtonRenderer.Android? @PureWeen @Clancey

XF에는 Compressed Layouts(버그가 있음)라는 것이 있습니다.
MAUI에 버그가 없는 것과 같은 것이 있습니까?

이 스레드에서 UI를 렌더링하기 위해 Flutter/Skia 접근 방식을 사용하는 것에 대해 사람들이 어떻게 반응하는지 보고 대부분 동의합니다.
MAUI가 네이티브/비네이티브 컨트롤 및 렌더링을 잠재적으로 지원하게 되어 정말 기쁩니다.
그러나 기본 UI로 작업할 수 있는 능력은 정치적인 측면에서 프레임워크를 확보한다고 말해야 합니다.
그리고 네, 저는 Apple에 대해 지적하고 있습니다. 최신 뉴스로 인해 어떤 시점에서 Flutter를 사용하는 것이 '문서화되지 않은/제한된 기능을 악용'하거나 'Apple UI 지침을 따르지 않음' 등으로 간주되더라도 놀라지 않을 것입니다.

이 스레드에서 UI를 렌더링하기 위해 Flutter/Skia 접근 방식을 사용하는 것에 대해 사람들이 어떻게 반응하는지 보고 대부분 동의합니다.
MAUI에서 잠재적으로 네이티브 컨트롤 및 렌더링이 아닌 사용자 지정을 지원하게 되어 정말 기쁩니다.
그러나 기본 UI로 작업할 수 있는 능력은 정치적인 측면에서 프레임워크를 확보한다고 말해야 합니다.
그리고 네, 저는 Apple에 대해 지적하고 있습니다. 최신 뉴스로 인해 어떤 시점에서 Flutter를 사용하는 것이 '문서화되지 않은/제한된 기능을 악용'하거나 'Apple UI 지침을 따르지 않음' 등으로 간주되더라도 놀라지 않을 것입니다.

MAUI가 웹(예: Flitter)을 지원하는 경우 항상 WebView로 렌더링할 수 있습니다.
일부 대기업은 WebView를 통해서만 AppStore에 표시되기 때문에 Apple은 WebView 기반 응용 프로그램을 감히 차단하지 않을 것입니다.

이 스레드에서 UI를 렌더링하기 위해 Flutter/Skia 접근 방식을 사용하는 것에 대해 사람들이 어떻게 반응하는지 보고 대부분 동의합니다.
MAUI에서 잠재적으로 네이티브 컨트롤 및 렌더링이 아닌 사용자 지정을 지원하게 되어 정말 기쁩니다.
그러나 기본 UI로 작업할 수 있는 능력은 정치적인 측면에서 프레임워크를 확보한다고 말해야 합니다.
그리고 네, 저는 Apple에 대해 지적하고 있습니다. 최신 뉴스로 인해 어떤 시점에서 Flutter를 사용하는 것이 '문서화되지 않은/제한된 기능을 악용'하거나 'Apple UI 지침을 따르지 않음' 등으로 간주되더라도 놀라지 않을 것입니다.

MAUI가 웹(예: Flitter)을 지원하는 경우 항상 WebView로 렌더링할 수 있습니다.
일부 대기업은 WebView를 통해서만 AppStore에 표시되기 때문에 Apple은 WebView 기반 응용 프로그램을 감히 차단하지 않을 것입니다.

그것은 이미 지침에 위배됩니다 - https://developer.apple.com/app-store/review/guidelines/#minimum -functionity

MAUI의 이 완전히 새로운 세계가 무엇인지 다시 한 번 읽고 네 번째로 읽은 후, 거룩한 모든 사람의 사랑을 위해 실제로 SKIA 또는 기타 다중 플랫폼 렌더링 엔진과 같은 렌더링 엔진을 어디에서나 사용하고 사용자 정의를 구현해야 합니다. Xamarin Forms와 같은 각 플랫폼의 UI는 마치 지옥의 일곱 번째 서클에서 만든 솔루션처럼 오래되고 오래된 느낌입니다.

이전 버전과의 호환성이 필수인 경우 새롭고 현대적인 렌더 지원을 이전 구성 요소를 렌더링하는 방법으로 "그냥" 만들어야 합니다. 다른 플랫폼에서 이에 대한 깔끔한 솔루션을 제공하는 것을 보았습니다. 가장 최근에 사용한 것은 Unity의 UI 엔진에 있습니다. 새로운 최신 UXML에는 IMGUI 렌더가 있습니다.

@jackie0100
난 전적으로 동의합니다

Xamarin Forms처럼 각 플랫폼에서 사용자 지정 UI를 구현해야 하는 것은 오래되고 지옥의 일곱 번째 서클에서 만든 솔루션인 것처럼 느껴집니다.

렌더러 구현에 관해서는, iView를의 아이디어에 대한 어떤 것은 네이티브 뷰 (대신 iView를의 기본보기가 있습니다)입니다. 즉, 구성 대신 상속? 이는 "양식 오버헤드"가 절대적으로 없는 가장 빠르고 간결한 아키텍처로 이어질 것입니다. 기본적으로 순수한 기본 보기와 공통 인터페이스로 작업하고 있습니다.

그런 다음 iOS 랜드에서 뷰를 UIView로 캐스팅하고 IView가 UIView이기 때문에 기본 자식(원하는 유형이 무엇이든)을 추가하는 것과 같은 작업을 수행할 수 있습니다. 마찬가지로, '네이티브 임베딩'을 하고 싶다면 IView가 UIView이기 때문에 쉽습니다. IView 중 하나를 네이티브 뷰에 추가하면 됩니다. 같은 것이기 때문입니다. 이것은 네이티브 <-> maui 상호 운용성을 최대한 활성화하고 최고 수준의 성능과 최저 메모리 소비를 가능하게 합니다.

직접 프로토타이핑을 하고 싶은 기분이 듭니다. 아마도 주말/저녁 프로젝트...

MAUI가 웹(예: Flitter)을 지원하는 경우 항상 WebView로 렌더링할 수 있습니다.

iOS에서는 WebView가 필요하지 않습니다. OpenGL 또는 Metal 에서 직접 렌더링할 수 있습니다.

또는 OpenGL 또는 Metal과 함께 Skia를 사용하십시오.

네이티브 UI로 작업하는 기능은 사물의 정치적 측면에서 프레임워크를 보호합니다. [사과]

어느 시점에서 Apple은 서면 정책에서 기본 UI 위젯을 사용해야 하는 요구 사항을 삭제했습니다. 나는 그들이 정책을 다시 제한적으로 되돌릴 실질적인 방법을 보지 못합니다.

그럼에도 불구하고 기본 컨트롤을 사용하는 _가능_한 것은 좋은 선택입니다.

@legistek

많은 사람들이 Skia에 열광하는 이유는 무엇입니까? 좋은 렌더링 사양은 렌더링 엔진과 무관합니다...

"불관론"이라는 것에 전적으로 동의하지만 OpenGL/Metal/Vulkan/저수준 렌더링 엔진으로 직접 이동하는 경우 대화형 UI를 렌더링하기 위해 구현해야 하는 세부 사항이 _많은_ 있습니다. 사람들은 Skia가 앱의 UI 문제와 실제 렌더링 엔진 사이의 효과적인 _중간 계층_이기 때문에 Skia에 집착합니다. Skia는 베어 메탈만 있다면 설계 및 구현해야 하는 것의 _많은_을 처리합니다. 이 작품을 재발명할 이유가 없습니다. _only_ 대상이 되어서는 안 되지만 매우 가치 있고 성숙한 대상이므로 OpenGL에서 Vulkan으로 훨씬 쉽게 이동할 수 있습니다.

또한 Skia를 대상으로 하는 것이 Xamarin Forms에서 플랫폼 간 위젯과 기본 위젯이라는 두 개의 병렬 위젯 계층을 유지 관리하는 것보다 훨씬 덜 번거롭지 않을까 생각합니다.

Skia는 .Net Maui가 브라우저 에서 고성능을 발휘하는 날을 앞당길 수도 있습니다. 다시 말하지만, 렌더링의 낮은 수준에서 구축하는 대신 적절한 중간 수준 추상화에서 시작하기 때문입니다. 그것은 큰 승리가 될 것입니다.

안녕하세요 여러분, 잊지 마세요.
https://github.com/dotnet/maui/discussions/103

최근 마우이 비디오를 본 결과, 내가 실수하지 않는 한 플랫폼 독립 측면에서 수행된 그림으로 오버레이되는 네이티브 컨트롤과 함께 더 스타일이 지정된 컨트롤을 갖는 경향이 있었던 것 같습니다. 그것의 skia이든 네이티브 캔버스 드로잉에 대한 일종의 배치 interop이든 이 접근 방식이 추구되기를 바랍니다! XF 플랫폼 렌더러 모델은 항상 아이러니하게도 가장 적게 사용되는 Microsoft UI 플랫폼에 가장 큰 피해를 입혔습니다.

또한 컨트롤이 네이티브 구성 요소를 명시적으로 갖지 않도록 하고 레이아웃 합성기가 이를 감지할 수 있는 기능을 열어 둡니다. 그러면 생성된 네이티브 뷰가 자동으로 축소될 수 있습니다(즉, 컨테이너의 모든 컨트롤이 skia의 경우 컨테이너를 SkView로 만들고 레이블 자식 컨트롤에서 그리기 작업을 호출할 수 있습니다.

I do not understand what a renderer is.
If the program for absorbing the visual differences of the target is called a renderer, it should be absorbed by Xamarin and MAUI altogether. If not, I think it 's an unfinished Xamarin and MAUI. And it will never be completed.
I think application programming should be more independent of the differences in the target environment.

렌더러라는 것이 이해할 수 없습니다.
대상의 비주얼에 대한 차이를 흡수하기위한 프로그램을 렌더러라고한다면, 그것은 Xamarin과 MAUI이 모두 흡수해야합니다. 그렇지 않을 것이라고하면 그것은 Xamarin도 MAUI도 미완성이다라고 생각합니다. 그리고 그것은 영원히 완성하는 것은 없을 것입니다.
응용 프로그래밍은 더 대상 환경의 차이에서 독립 할 수 있도록해야한다고 생각합니다.