अन्य यादृच्छिक विचार (सभी मेरे नहीं):

• हम वास्तव में ऐसे प्रारूप का समर्थन करने से बचना चाहते हैं जहां ऐसी सुविधाओं को लागू करने की पहले से अपेक्षा है जो प्रदर्शनकारी नहीं होने जा रही हैं। उदाहरण के लिए, एसवीजी को लागू करने से लोग स्क्रिप्टिंग, एचटीएमएल, एसएमआईएल आदि सहित पूर्ण एसवीजी समर्थन की अपेक्षा करेंगे।
• हमें अपने प्रारूप को स्कीया में प्रदर्शन सुविधाओं के साथ स्पष्ट रूप से बहुत बारीकी से डिजाइन करना चाहिए, उदाहरण के लिए ड्रॉएटलस।

वेक्टर समर्थन एक ऐप ढांचे के लिए महत्वपूर्ण लगता है जो विभिन्न स्क्रीन आकारों और घनत्वों का समर्थन करता है। अन्यथा आप ऐसे आइकनों के साथ समाप्त होते हैं जो इस तरह दिखते हैं:

इसके अलावा:

@HansMuller

क्रिस ने इसका भी उल्लेख किया: हम निर्माण के समय कुछ सीमित एसवीजी प्रसंस्करण कर सकते थे। उदाहरण के लिए हम एसवीजी विवरण के आधार पर एमडी आइकन विजेट उत्पन्न कर सकते हैं। यदि सावधानी से किया जाए तो यह स्थान बचा सकता है और मूल डिजाइनों के प्रति निष्ठा बढ़ा सकता है।

विशेष रूप से सामग्री डिज़ाइन आइकन के लिए, हमें सामग्री डिज़ाइन आइकन फ़ॉन्ट का उपयोग करके जांच करनी चाहिए।

@appsforartists इसके लायक क्या है, न तो कोको और न ही android.view आइकन के लिए वेक्टर प्रारूपों का उपयोग करते हैं।

@abarth मुझे iOS के बारे में आश्चर्यचकित नहीं करता है - ऐसा लगता है जैसे उन्होंने एक हार्डकोडेड 3.5 "स्क्रीन के साथ शुरुआत की है और तब से उस मानसिक मॉडल/समर्थित संकल्पों की सादगी को बनाए रखने के लिए बहुत कठिन प्रयास किया है (देखें: प्रत्येक iPhone की चौड़ाई समान है, या मूल iPad और iPad मिनी में समान रिज़ॉल्यूशन है। मुझे मोबाइल विकास के बारे में ज्यादा जानकारी नहीं है, लेकिन एंड्रॉइड के वेक्टर-आधारित नहीं होने के बारे में यह थोड़ा आश्चर्यजनक है।

किसी भी स्थिति में, आइकनों को अलियास नहीं दिखना चाहिए जैसा कि वे उपरोक्त स्क्रीनशॉट में करते हैं, और वेक्टर संकल्प स्वतंत्रता के लिए एक अच्छा समाधान हैं। सुंदर आइकनों को हल करने के लिए आप लोग कैसे लागू करना चुनते हैं, यह आप पर निर्भर है। :स्माइली:

सुंदर आइकनों को हल करने के लिए आप लोग कैसे लागू करना चुनते हैं, यह आप पर निर्भर है।

क्या आप उस समाधान समस्या के बारे में एक अलग मुद्दा दर्ज करने के इच्छुक होंगे जिसे आप आइकनों के साथ देख रहे थे? @krisgiesing ने एक संकल्प-जागरूक संपत्ति समाधानकर्ता लागू किया जो कई मामलों को संभालता है। उन मामलों के बारे में जानना मूल्यवान होगा जिन्हें यह संभालता नहीं है।

मैं वर्तमान समाधान जागरूकता समर्थन के लिए कुछ परीक्षण जोड़ने पर विचार कर रहा हूं, इसलिए अब यह समझने का एक अच्छा समय होगा कि क्या कुछ ठीक से काम नहीं कर रहा है।

ऐसा लगता है कि 3x का डिवाइस पिक्सेल अनुपात 2.6 है, जिसके लिए शायद हमारे पास कोई एसेट नहीं है।

मैं अब इस विशिष्ट मामले को देख रहा हूं। डिवाइस पिक्सेल अनुपात 2.625 है; हम 3.0x संपत्ति का चयन कर रहे हैं, जो अपेक्षित है। हालाँकि, ऐसा लगता है कि प्रतिपादन के दौरान कुछ ऐसा हो रहा है जो किसी प्रकार की अतिरिक्त अलियासिंग कलाकृतियों का कारण बन रहा है। इसलिए हालांकि @abarth ने एक फ़ॉन्ट पर स्विच करके सामग्री डिज़ाइन आइकन के मामले को ठीक कर दिया, मैं अभी भी अन्य प्रकार की छवि संपत्तियों की ओर से जांच कर रहा हूं, जिन्हें रिज़ॉल्यूशन निर्भर स्केलिंग की आवश्यकता है।

मैं इसे ट्रैक करने के लिए एक और बग खोलूंगा क्योंकि यह वेक्टर प्रारूप के समर्थन के लिए स्पर्शरेखा है।

देखें #2337

एंड्रॉइड "वेक्टर ड्रावेबल" प्रारूप का समर्थन करता है जो एसवीजी का सिर्फ एक अच्छा प्रदर्शन करने वाला सबसेट है। मुझे आशा है कि आप उसी प्रारूप का उपयोग करने पर विचार करेंगे, यह देखते हुए कि इसमें पहले से ही कुछ सामुदायिक समर्थन है और एंड्रॉइड टीम ने स्पष्ट रूप से इसके प्रदर्शन को पर्याप्त माना है।

वेक्टर ड्रावेबल निश्चित रूप से एसवीजी से प्रभावित है लेकिन यह सबसेट नहीं है। इसके अलावा यह एक्सएमएल का उपयोग करता है, जो काफी हद तक गारंटी देता है कि यह सबसे अधिक प्रदर्शन करने वाला वेक्टर प्रारूप नहीं होगा जिसके साथ कोई भी आ सकता है। :-)

वेक्टर ड्रावेबल को सख्त उपसमुच्चय के रूप में वर्णित करना गलत था, लेकिन यह अभी भी अच्छा _render_ प्रदर्शन और उपयोग में आसानी सुनिश्चित करने के बीच एक संतुलित समझौता प्रतीत होता है। वेक्टर ड्रॉएबल विनिर्देश अक्सर पथ डेटा सिंटैक्स जैसे प्रमुख क्षेत्रों के लिए एसवीजी विनिर्देशन को टाल देता है, जिससे एसवीजी संपत्तियों को परिवर्तित करना बहुत आसान हो जाता है, जो कि कई डेवलपर्स पहले से ही वेक्टर ड्रावेबल्स का उपयोग और साझा करते हैं जो मौजूदा एंड्रॉइड ऐप में पहले से मौजूद हैं।

मैं कल्पना नहीं कर सकता कि एक्सएमएल एक महत्वपूर्ण प्रदर्शन अवरोधक है क्योंकि यह केवल पार्सिंग को प्रभावित करता है। मुझे ऐसा लगता है कि _render_ प्रदर्शन - जिस तरह का प्रदर्शन फ़्लटर के 60fps ऐप्स के लक्ष्य को प्रभावित करता है - वह वेक्टर संचालन के सेट पर अधिक निर्भर है जिसे स्की को आकर्षित करना होगा, न कि एक पार्सिंग चरण जिसे एक बार किया जा सकता है और कैश किया जा सकता है।

मैं इस मुद्दे पर और अधिक चर्चा नहीं करना चाहता लेकिन मैं यह महसूस करने में मदद नहीं कर सकता कि इसके लिए काम पहले ही किया जा चुका है और इसलिए "2.0 रिलीज के बाद" मील के पत्थर में बंद होने की आवश्यकता नहीं है।

हमने सामग्री डिज़ाइन आइकन के लिए सामग्री डिज़ाइन फ़ॉन्ट का उपयोग करना समाप्त कर दिया। मुझे किसी भी बाधा के बारे में पता नहीं है जो किसी को सीधे dart:ui कॉल या कस्टमपेंट विजेट का उपयोग करके स्पंदन के शीर्ष पर इसे बनाने से रोक रहा है: https://docs.flutter.io/flutter/widgets/CustomPaint-class। एचटीएमएल. इस समय इस तरह के निर्माण की हमारी कोई तत्काल योजना नहीं है।

$.02 - यहां तक ​​कि जानदार ब्राउज़र ( और प्रतिस्पर्धी ढांचा रिएक्ट नेटिव कोई बात नहीं, उनका समाधान हैकी है) एसवीजी प्रस्तुत कर सकता है। छवि निर्यात विकल्प के लिए मेरी टीम के लिए प्रत्येक आइकन या कला संपत्ति के लिए न्यूनतम 3 फ़ाइलें बनाने की आवश्यकता है। एक एसवीजी फ़ाइल की तुलना में यह एक खराब अभ्यास है जिसे किसी भी रिज़ॉल्यूशन पर प्रदर्शित किया जा सकता है।

हिक्सी द्वारा उपरोक्त टिप्पणी के लिए, पूर्व-मौजूदा उम्मीदों को एक सार्थक सुविधा को लागू करने में बाधा नहीं डालनी चाहिए। मैं एसवीजी डिस्प्ले (जो मेरे और मेरी टीम के लिए कई समस्याओं को हल करता है) के लिए बुनियादी समर्थन प्राप्त करने में सक्षम होगा और यह पता लगाने के लिए विस्तारित विकल्प उपलब्ध नहीं हैं कि पीएनजी की लगातार बढ़ती संख्या को समायोजित करने के लिए स्क्रीन रिज़ॉल्यूशन की संख्या।

मैं अपनी टीम के लिए एक फ़ॉन्ट बनाने के लिए वापस आ रहा हूं लेकिन यह मूल एसवीजी समर्थन जितना अच्छा नहीं है क्योंकि फ़ॉन्ट प्रारूप लाइन-ऊंचाई और अक्षर अंतर के लिए अतिरिक्त स्वरूपण जोड़ता है जिसे ऐप में समायोजित किया जाना है। इसके अलावा, फोंट निश्चित प्रस्तावों (12px, 16px, 20px, 36px...) पर प्रदर्शित होना चाहते हैं जो कि सीमित भी है।

कूल स्पंदन ढांचे के लिए धन्यवाद। :)

मैं किसी को भी प्रोत्साहित करूंगा जो एसवीजी समर्थन चाहता है ताकि एसवीजी समर्थन को स्पंदन के लिए डार्ट पैकेज के रूप में लागू किया जा सके।

रुचि रखने वालों के लिए, मैं https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html को इंगित करता हूं जो ड्राइंग के लिए निम्न-स्तरीय लाइब्रेरी है।

टीम से: डार्ट पुस्तकालय पर्याप्त समाधान नहीं है। बस इसे पास कर रहे हैं।

क्या आप इसे विस्तार में बताने में सक्षम हैं? फ़्लटर का संपूर्ण ढांचा एक डार्ट पुस्तकालय है; हम यहां जो कुछ भी लागू करते हैं वह संभवतः एक डार्ट पुस्तकालय होगा। "काफी अच्छा" के लिए क्या आवश्यकताएं हैं?

मामले में, मैंने कुछ समय पहले शुद्ध-डार्ट में एक (सरल, गैर-संपूर्ण) एसवीजी पार्सर लागू किया था:

https://github.com/matanlurey/svg

यह संभवतः कुछ हद तक तुच्छ होगा:

ए। एक रनटाइम बनाएं SVG -> SvgRenderElement , जो dart:ui अंडर-द-हुड का उपयोग करता है।
बी। एक बिल्ड-टाइम संकलन चरण बनाएं जो एक एसवीजी को कुछ इस तरह परिवर्तित करता है:

// compiled from star.svg
void drawStarSvg(canvas, width, height) { ... }

@ deborah-ufw यदि आप रुचि रखते हैं, तो हम और जानने के लिए चैट करना पसंद करेंगे। क्या आप मुझे ईमेल कर सकते हैं?

हाय सेठ, मटनलुरे और हिक्सी - प्रतिक्रिया के लिए बहुत-बहुत धन्यवाद। मैं शायद गहराई से बात करने के लिए सही व्यक्ति नहीं हूं, क्योंकि यह हमारे प्रमुख इंजीनियर थे जिन्होंने डार्ट प्लगइन समाधान को अस्वीकार कर दिया था (इस प्रकार हमारे ऐप के लिए पीएनजी की एक विशाल लाइब्रेरी का निर्माण हुआ, जो हम में से अधिकांश को भी परेशान करता है)।

मैं इस गीथूब मुद्दे के लिए लिंक उन्हें पास करना चाहता हूं और उनसे उनकी टिप्पणी के लिए तकनीकी कारणों का योगदान करने के लिए कहता हूं (जो कि मेरे द्वारा पारित होने की तुलना में अधिक रंगीन रूप से बनाया गया था) - जैसे ही मैं टाइपिंग समाप्त कर दूंगा, मैं ऐसा करूंगा।

वे http://gitter.im/flutter/flutter के साथ-साथ जरूरत पड़ने पर https://flutter.io/support/ सूचीबद्ध अन्य संपर्क विधियों के माध्यम से सीधे हमारे इंजीनियरों के साथ चैट करने में सक्षम हैं। :)

मैं इसमें जोड़ दूंगा। धन्यवाद! :डी

एक अन्य तरीका यह है कि http://svgpp.org/ जैसी किसी चीज़ को मूल स्तर पर एकीकृत किया जाए और इसके साथ संवाद करने के लिए फ़्लटर प्लगइन सिस्टम का उपयोग किया जाए। यह संभवतः आपको पूर्ण SVG समर्थन के लिए सर्वोत्तम आकार/प्रदर्शन विशेषताएँ देगा, लेकिन एक निर्भरता बनाए रखने की कीमत पर।

इंजन स्तर पर एसवीजी समर्थन की तलाश के बारे में क्या? मुझे नहीं लगता कि मानक के पूर्ण समर्थन की अपेक्षा करना उचित या वांछनीय है, लेकिन अपील का हिस्सा क्रॉस फंक्शनल टीमों और मौजूदा टूलिंग के लिए समर्थन है।

मुझे आभास हुआ कि स्कीया कुछ बुनियादी एसवीजी समर्थन प्रदान करता है। क्या स्पंदन के लिए इसे उपलब्ध कराने का कोई तरीका नहीं है?

मैं जो कह सकता हूं, वह केवल प्रयोगात्मक और आंशिक रहा है। यहाँ एक समस्या खुली है https://bugs.chromium.org/p/skia/issues/detail?id=5596 बिट यह एक वर्ष से अधिक पुराना है। वे इसे अपने रोडमैप में भी सूचीबद्ध कर रहे हैं लेकिन फिर से यह स्पष्ट नहीं है कि प्राथमिकता क्या है।

इंजन स्तर पर एसवीजी का समर्थन करने का कोई मतलब नहीं होगा क्योंकि इससे एसवीजी दस्तावेज़ मॉडल का पर्दाफाश नहीं होगा, जो एसवीजी समर्थन का एक मुख्य हिस्सा है।

यदि स्पंदन एसवीजी का समर्थन करता है, तो यह वास्तव में वास्तविक एसवीजी का समर्थन करने के अंतिम लक्ष्य के साथ होगा। यह सुविधाओं के आधे-अधूरे कार्यान्वयन के लिए फ़्लटर के दर्शन के विरुद्ध है।

मैं एसवीजी दस्तावेज़ मॉडल को एसवीजी समर्थन के मुख्य भाग के रूप में उजागर नहीं करता। यह एक अच्छा होगा लेकिन मेरे दिमाग में उपयोग के मामलों के लिए जरूरी नहीं है।

हां, पुस्तकालय स्तर का समर्थन अधिक सुविधाओं को सक्षम करेगा - लेकिन अगर इंजन स्वयं एसवीजी डेटा (एक महत्वपूर्ण उपसमुच्चय) को प्रस्तुत करने में सक्षम था, तो संभवतः एसवीजी के उस सबसेट द्वारा परिभाषित वेक्टर छवि संपत्तियों को प्रस्तुत करने की अनुमति देने के लिए पर्याप्त होगा।

यह मुद्दा स्पष्ट रूप से उससे बड़ा है, लेकिन मुझे मौजूदा एसवीजी संपत्तियों को लेने और उन्हें अलग-अलग प्रस्तावों पर ठीक से प्रस्तुत करने में खुशी होगी, उन सभी को भारी रेखापुंज छवियों में परिवर्तित किए बिना।

हाँ, एसवीजी परिसंपत्ति फ़ाइल आयात वास्तव में अच्छा होगा लेकिन एसवीजी के लिए कल्पना 800 पृष्ठों से अधिक लंबी है। यह कहकर कि स्की (जो एक वेक्टर ग्राफिक्स लाइब्रेरी है) पर प्रस्तुत करने के लिए स्थिर फ़ाइलों को आयात करने के लिए कोई समस्या नहीं होनी चाहिए। तो मैं इसे ले रहा हूँ; हमेशा की तरह मैं केवल सप्ताहांत पर अंशकालिक काम कर सकता हूं ताकि आपको तुरंत सामान दिखाई न दे। इसके अलावा मेरे पास एसवीजी फाइलों का एक टन है लेकिन वे सभी एक ही सामान (फ्लैटिकॉन से आइकन संग्रह) का उपयोग करते हैं, इसलिए मैं उन लोगों से नमूना एसवीजी फाइलों की सराहना करता हूं जो यह सुविधा चाहते हैं।

कार्लोस।

मैं समय के साथ इस पर थोड़ा सा नूडल भी कर रहा हूं। यहाँ मैं क्या लेकर आया हूँ:

इंजन स्तर का कार्यान्वयन

यह निम्नलिखित कारणों से आकर्षक लगता है:

1. सिद्धांत रूप में कुछ C/C++ कोड पार्स करने के लिए image: new AssetImage('graphics/background.svg') जैसी किसी चीज़ का समर्थन करता है और SVG डेटा को स्कीया रेंडरिंग कमांड में अनुवाद करता है
2. कम से कम एक अच्छा उम्मीदवार जो इंजन स्तर पर काफी आसानी से स्की में प्लग इन करने में सक्षम होना चाहिए (https://github.com/svgpp/svgpp)
3. WebKit का SVG लॉजिक कमाल का होगा लेकिन लगता है कि इसमें बहुत अधिक निर्भरताएँ हैं
4. मुझे नहीं लगता कि librsvg बहुत अच्छी तरह से पोर्ट करेगा (काहिरा के साथ कसकर, एक प्राथमिक भाषा के रूप में रस्ट में संक्रमण - कम से कम बैकएंड के रूप में स्की को प्राप्त करने के लिए काम करने की आवश्यकता होगी)

लेकिन इसमें कम से कम कुछ कठिनाइयाँ हैं:

• पाठ को ठीक से संभालना
• CSS को ठीक से संभालना (यदि बिल्कुल भी हो तो? लेकिन इसे जोड़ना कोई आसान काम नहीं है)
• अतिरिक्त सुविधाओं के लिए समर्थन प्रदान करना (या उपयोगकर्ताओं को सुविधाओं के लिए अधिक आकर्षक ढंग से समर्थन जोड़ने की अनुमति देना) चुनौतीपूर्ण है।
• ऐसा लगता है कि एनिमेशन को संभालना बहुत मुश्किल है

डार्ट स्तर का कार्यान्वयन

1. स्पंदन का dart:ui स्कीया से बहुत सारे आदिम प्रदान करता है जिसे एसवीजी को पहले से ही चाहिए
2. मुझे संदेह है कि इंजन स्तर की तुलना में इस स्तर पर पाठ प्रतिपादन अधिक आसानी से नियंत्रित किया जाएगा
3. अधिक समुदाय के लिए बनाए रखना/विस्तार करना आसान होना चाहिए
4. पार्सिंग तर्क (शायद अपवादों और/या एनिमेशन को संभालने के लिए?)

लेकिन कुछ कठिनाइयाँ हैं:

• सीएसएस का समर्थन करने से बेहतर नहीं हो सकता
• बेहतर सहायक एनिमेशन नहीं कर सकते हैं
• संभवतः धीमा होगा (लेकिन शायद पर्याप्त नहीं है, और संभावित रूप से एओटी संकलित एसवीजी द्वारा डार्ट कोड में ऑफसेट किया जा सकता है)

परीक्षण डेटा

जहां तक ​​नमूना एसवीजी की बात है, तो शायद यह पहचानना सबसे उपयोगी होगा कि 1.1 परीक्षण सूट से एसवीजी क्या समर्थित हैं (या, यदि आंशिक रूप से समर्थित हैं, तो उनके बारे में क्या आंशिक रूप से समर्थित है)। वे यहां पाए जा सकते हैं:
https://github.com/w3c/web-platform-tests/tree/master/svg/import

या यहाँ कुछ PNG तुलनाओं के साथ: https://www.w3.org/Graphics/SVG/Test/20110816/

@cbazza , आप इसे किस तरह से लागू करने की सोच रहे हैं? इस समय, मैं डार्ट पैकेज स्तर के कार्यान्वयन की ओर अधिक झुक रहा हूँ।

साथ ही, मुझे लगता है कि आइकन प्रकार का समर्थन शायद आसानी से IconData जैसी किसी चीज़ से नियंत्रित किया जाता है। इसे अलग से इलाज करना सबसे अच्छा हो सकता है, क्योंकि इसे प्रति कोडपॉइंट केवल एक पथ का समर्थन करना होगा

मैं डार्ट के शीर्ष पर 'डार्ट स्तर कार्यान्वयन' के बारे में सोच रहा हूँ : ui।

2 बुनियादी उपयोग के मामले:

(1) अपने जैसे कुछ के साथ स्थिर आइकन svg फ़ाइलें लोड करें
"छवि: नया एसेटइमेज ('ग्राफिक्स/बैकग्राउंड.एसवीजी')", जहां
फ़ाइल फ़ाइल सिस्टम या नेटवर्क से आ सकती है
गतिशील रूप से।

(2) डीएसएक्स के साथ विजेट आधारित एसवीजी समर्थन (जेएसएक्स जैसे निर्माण)
जो बहुत समान दिखाई देगा:
https://github.com/react-native-community/react-native-svg

'टेस्ट डेटा' के संबंध में मुझे उन लोगों की वास्तविक फाइलों की आवश्यकता है जिनकी आवश्यकता है
यह और नहीं w3 परीक्षण सूट। एसवीजी समर्थन निर्भर होगा
किस डार्ट पर: ui समर्थन करता है, यदि एक resred svg फ़ाइल में शामिल है
सामान जो dart:ui के साथ नहीं किया जा सकता, मैं कर पाऊंगा
जल्दी पता करो।

कार्लोस।

मुझे नहीं लगता कि हमें रिएक्ट नेटिव एसवीजी मॉडल के लिए जाना चाहिए। मैं वास्तविक जीवन के मामलों का समर्थन करना चाहता हूं, मुझे लगता है कि डब्ल्यू 3 सूट को कवर करने से हमें बेहतर आधार मिलेगा कि क्या काम करता है और क्या नहीं और इसे लागू करना कितना चुनौतीपूर्ण होगा)

ठीक है, लगता है कुछ ग़लतफ़हमी हो रही है...
जब मैं (1) करता हूं तो यह मानक एसवीजी फाइलें लेगा और मैं जितना डार्ट दे सकता हूं उतना समर्थन करने की कोशिश करूंगा: यूआई (स्किया)।
जब मैं (2) करता हूं, जो एसवीजी जैसे निर्माणों को संभालने के लिए विजेट बना रहा है तो यह उस प्रतिक्रिया-मूल-एसवीजी पुस्तकालय के समान ही दिखाई देगा। ये 2 बहुत अलग चीजें हैं।

@cbazza हमारे ऐप में svgs के लिए उपयोग का मामला मुख्य रूप से एक-रंग के svgs के लिए है जिसे हम आइकन के रूप में उपयोग करते हैं। यहां ड्रॉपबॉक्स पर एक ज़िप फ़ाइल का लिंक दिया गया है जिसमें हाल के svgs के चयन के साथ प्रतिनिधि हैं। https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

यहां मदद करने में रुचि के लिए धन्यवाद, मुझे यह देखकर खुशी होगी कि एक एसवीजी स्पंदन प्लगइन जीवन में आ रहा है!

मैंने एक उपकरण लिखा है जो कुछ हद तक एसवीजी फाइलों के अनुक्रम की कुछ न्यूनतम पार्सिंग करता है और डार्ट फाइलों को डंप करता है जिसे हम बाद में आइकन एनिमेशन दिखाने के लिए उपयोग करते हैं: vitool ।

मैंने एनिमेटेड आइकन डेटा बनाने के लिए इस टूल का उपयोग किया है, आप मैन्युअल परीक्षण ऐप ( cd dev/manual_tests; flutter run -t lib/animated_icons.dart ) चलाकर परिणाम की जांच कर सकते हैं।

यह इष्टतम या पूर्ण होने से बहुत दूर है, लेकिन हमारे पास मौजूद एनिमेटेड आइकन के वर्तमान सेट के लिए काम करता है, और किसी को इसे कांटा/विस्तार करने के लिए सशक्त महसूस करना चाहिए।

@ deborah-ufw इन सिंगल कलर आइकन के लिए आप जो कुछ कर सकते हैं वह एक आइकन फ़ॉन्ट बनाना है, और आइकन विजेट का उपयोग करके आइकन दिखाना है।

@amirh रंग वेक्टर फोंट बनाना आसान नहीं लगता

@amirh यदि आप ऊपर दिए गए पूरे धागे को पढ़ते हैं, तो ग्लिफ़ के साथ एक फ़ॉन्ट को आइकन के रूप में बनाना और परिभाषित करना कदमों की एक अतिरिक्त श्रृंखला है जिसे लिया जाना है क्योंकि एसवीजी समर्थित नहीं है। SVG सपोर्ट किसी फॉन्ट की तुलना में कहीं अधिक कुशल है। इसके अलावा, ज़ोइची सही है - कोई भी वेक्टर कला जिसमें कई रंग होते हैं, एक फ़ॉन्ट में बनाना लगभग असंभव है।

क्षमा करें - मैंने नमूना चिह्नों को देखा और सोचा कि आपको केवल एकल रंग चिह्नों की आवश्यकता है।

@ डेबोरा-यूएफडब्ल्यू, फाइलों के लिए धन्यवाद, ठीक वही जो मैं ढूंढ रहा था और पहले से ही वह सामान मिला जो मेरी फाइलों में नहीं है।

@amirh , हाँ मैंने आपका महान काम पहले ही देख लिया है;)

क्या हमारे पास स्पंदन के लिए छवि में svg या वेक्टर एसेट xml को स्रोत करने का एक सीधा तरीका है

@ हिक्सी : कृपया (पुनः) विचार करें कि मल्टी-प्लेटफ़ॉर्म देशी मोबाइल टीमों के लिए यह एक वास्तविक दर्द बिंदु है, लेकिन इसे हल करने के लिए केवल आंशिक, अपेक्षाकृत सरल एसवीजी समर्थन की आवश्यकता है। एसवीजी मानक अनुरक्षकों के लिए इसे आधे मन से माना जा सकता है, लेकिन स्पंदन मोबाइल डेवलपर्स के लिए है, सामान्य मानक लेखकों के लिए नहीं। स्पंदन मोबाइल डेवलपर्स का दिल जीत लेगा यदि यह उनके वास्तविक दर्द को कम करता है, भले ही यह केवल व्यावहारिक तरीके से ही क्यों न हो।

कृपया इस बात पर भी विचार करें कि इस लंबे समय से मौजूद आवश्यकता के बावजूद, सामुदायिक समर्थन दृष्टिकोण फ़्लटर प्रतियोगी ज़ामरीन में व्यावहारिक समाधान उत्पन्न करने में विफल रहा है (मेरे 5 वर्षों के ज़ामरीन अनुभव में - लिबास डिज़ाइन टूल निर्यात को संभाल नहीं सकते हैं, बहुत सीमित हैं, स्थिर नहीं हैं, भुगतान और/या बंद स्रोत)।

इस वजह से मैं आशावादी नहीं हूं कि जहां ज़ामरीन समुदाय विफल हुआ, वहां फ़्लटर समुदाय सफल होगा। मैं अनुमान लगाता हूं कि एक व्यावहारिक। एसवीजी आइकन के लिए आंशिक समर्थन कुछ ऐसा है जो फ़्लटर टीम मौजूदा स्कीया प्राइमेटिव का उपयोग करके वितरित कर सकती है।

यह फ़्लटर लक्ष्य को अच्छी तरह से फिट करेगा: मोबाइल डेवलपर्स को रिकॉर्ड समय में सुंदर, उच्च प्रदर्शन UX देने में सक्षम बनाता है। यह उत्पादकता, निष्ठा और प्रदर्शन में सुधार करेगा (एक एसवीजी उन सभी पीएनजी की तुलना में बहुत तेजी से लोड होता है; आइकन एसवीजी की आम तौर पर मामूली कम्प्यूटेशनल लागत होती है क्योंकि दृश्य स्पष्टता की आवश्यकता अक्सर मामूली जटिलता के आकार की ओर ले जाती है)।

आमतौर पर उपयोग किए जाने वाले क्रिएटिव डिज़ाइनर टूल (जैसे Adobe) से लेकर स्केलेबल नेटिव ऐप आइकॉन तक उत्पादक वर्कफ़्लो की मुख्य आवश्यकता है।

उत्पादकता और ऐप आकार के मामले में वर्तमान पीएनजी दृष्टिकोण बहुत बेकार है; यह 9 निश्चित बिटमैप्स (6 एंड्रॉइड, 3 आईओएस) तक प्रत्येक आइकन को उत्पन्न और शिप करने के लिए बहुत ही आदिम है, जिसे बाद में रनटाइम पर पोस्ट-प्रोसेस किया जाता है। समस्या लगातार बढ़ती जाती है क्योंकि संकल्प आकार और भिन्नता में वृद्धि करते हैं।
यह अन्यथा रमणीय अभिनव और उत्पादक Flutter डेवलपर अनुभव में एक गले में अंगूठे के रूप में चिपक जाता है। मुझे लगता है कि फ़्लटर के पास यहां देवों के दिल और दिमाग जीतने का एक वास्तविक अवसर है,

इसके अलावा @dnfield उपर्युक्त एसवीजी सुविधाओं का उल्लेख किया गया है जिन्हें फ़्लटर में लागू करने के लिए बाधाओं के रूप में उल्लेख किया गया है, मेरे अनुभव में या तो प्रासंगिक नहीं हैं या दुर्लभ हैं कि उन डिज़ाइन संपत्तियों के लिए पीएनजी में वापस आना एक छोटी सी असुविधा है।
परवाह नहीं: CSS, HTML, SMIL, दस्तावेज़ मॉडल, स्क्रिप्टिंग
ऐनिमेशन, टेक्स्ट: इतना दुर्लभ कि इसके लिए अन्य तकनीकों का उपयोग किया जा सके

मुझे आशा है कि इस टिप्पणी की लंबाई बताती है कि समाधान का कितना मूल्य होगा। हठ!

@ VincentH-नेट मैं आपके साथ 100% हूं क्योंकि मुझे भी दर्द होता है !!! कृपया मुझे अपनी कुछ एसवीजी फाइलें भेजें। शायद Xamarin एसवीजी समर्थन देने के लिए संघर्ष कर रहा था क्योंकि वेक्टर ग्राफिक्स इंजन की कमी थी जो इसे संभाल सकता था; यह स्कीया के साथ स्पंदन के लिए मामला नहीं है, इसलिए मैं बहुत आशावादी हूं कि एक सामुदायिक समाधान होगा।

FWIW, Xamarin में भी SkiaSharp में Skia उपलब्ध है। एसवीजी न्यूनतम कार्यान्वयन के लिए भी मुश्किल हो सकता है।

लेकिन @cbazza मुझे इस पर आपके साथ सहयोग करने में बहुत दिलचस्पी होगी

और एनीमेशन के मोर्चे पर, मुझे लगता है कि Lottie को सक्षम करने से बहुत सारे उपयोग के मामले संतुष्ट होंगे (और शायद इसे डिजाइनरों के लिए बेहतर टूलिंग के साथ करें)।

@dnfield मुझे लगता है कि इन Lottie एनिमेशन को फ़्लटर विजेट्स के रूप में आसानी से बनाया जा सकता है

@dnfield , उत्कृष्ट आप इंजन स्तर में परिवर्तन को संभालने वाले निम्न स्तर के व्यक्ति हो सकते हैं, जबकि मैं विजेट पर ऊपरी स्तर का काम करता हूं (async svg पार्सिंग, 'चित्र' निर्माण जिसे कैश किया जा सकता है और अद्यतनों को प्रस्तुत करने पर कैनवास पर भेजा जा सकता है)।
हां, डिजाइनर/डेवलपर वर्कफ़्लो के लिए लोटी काम करना बहुत अच्छा होगा।
@zoechi क्यों विजेट्स के साथ हाथ से कुछ का पुनर्निर्माण करते हैं जब आप बस एक काम कर रहे लोटी विजेट को आयात कर सकते हैं जो आपके लिए सब कुछ संभालता है? यह कहकर कि मेरा पिछला लक्ष्य (2) ऊपर विजेट एनिमेशन के साथ बहुत अच्छा काम करेगा (इसलिए मैं इसे भी क्यों करना चाहता हूं)।

@zoechi - लक्ष्य डिजाइनरों को ऐसी चीजें बनाने और डेवलपर के हिस्से पर न्यूनतम प्रयास के साथ प्रस्तुत करने में सक्षम बनाना होगा। एक माध्यमिक लक्ष्य उन्हें रनटाइम पर संसाधनों के रूप में लोड करने में सक्षम बनाना होगा, बजाय इसके कि प्रीकंपाइलेशन की आवश्यकता हो।

एसवीजी के लिए भी यही सच है - हां, एक डेवलपर निश्चित रूप से एसवीजी वेक्टर डेटा को डार्ट में बदल सकता है, लेकिन आदर्श रूप से आप केवल एक वेक्टर ड्राइंग (एसवीजी या नहीं) संसाधन शामिल कर सकते हैं और इसे रनटाइम पर प्रस्तुत कर सकते हैं।

दूसरे शब्दों में, मैं अपने डिजाइनर को एक बार वेक्टर संपत्ति बनाने के लिए कहना चाहता हूं और इसे अपने स्पंदन एप्लिकेशन में न्यूनतम संशोधन के साथ उपयोग करने में सक्षम होना चाहता हूं (और डिजाइनर के बिना इसे विभिन्न रेखापुंज प्रारूपों में 5 बार निर्यात किया जाता है जो समाप्त हो जाएगा जैसे ही Apple या Samsung अपना अगला फ़ोन जारी करते हैं, अमान्य हो जाते हैं)।

विभिन्न रेखापुंज प्रारूप

हाँ, यह पिछले दशक की तरह लगता है

https://github.com/luberda-molinet/FFImageLoading देखने लायक हो सकता है, Xamarin के लिए SVG रेंडर करने के लिए स्की का उपयोग करता है

@escamoteur

धन्यवाद, यह वास्तव में अच्छा लग रहा है, केवल एक चीज गायब है कि यह एसिंक नहीं है;)

मैं हाल ही में एंड्रॉइड एप्लिकेशन में केवल वेक्टर ड्रॉबल्स का उपयोग कर रहा हूं, और मुझे कोई ध्यान देने योग्य प्रदर्शन जुर्माना नहीं दिख रहा है। आइकॉन शार्प हैं और ऐप साइज काफी छोटा है। विभिन्न छवियों का परीक्षण करना भी बहुत आसान और तेज़ है। यह @2 , @3 , @4 , @5 ,.... समाधान स्पंदन जैसे आधुनिक ढांचे में एक बड़ा कदम पीछे जैसा दिखता है।
मुझे समझ में नहीं आता कि आप एंड्रॉइड वेक्टर ड्रॉबल्स के लिए ज़िम्मेदार टीम में क्यों नहीं जा सकते हैं, और उस समस्या को हल करने के लिए अपने विचारों या कार्यान्वयन (यदि संभव हो) का उपयोग क्यों नहीं कर सकते हैं।

मैं यहां कैनवास पर कुछ एसवीजी खींचे जाने के साथ घूम रहा हूं। path तत्व शायद लागू करने के लिए सबसे मुश्किल हैं, लेकिन एक स्की एपीआई है जो उजागर होने पर वास्तव में मदद करेगी। मैंने इसे इंजन में एक्सपोज़ करने के साथ प्रयोग किया है और इसे परिष्कृत करने के लिए थोड़ा और समय मिलने पर मैं पीआर खोलूंगा।

मोटा विचार कुछ ऐसा होगा जो हमें ऐसा करने के लिए पहले से मौजूद स्की एपीआई का उपयोग करके एसवीजी डेटा स्ट्रिंग से dart:ui Path बनाने की अनुमति देता है। प्रस्तावित विधि static Path Path.parseFromSvgData(String svgData) -> Path है

यह अभी भी लागू किए जा सकने वाले विभिन्न परिवर्तनों/स्ट्रोक/भरने को पार्स करने के आसपास कुछ काम छोड़ देता है। मुझे लगता है कि हम @amirh द्वारा किए गए काम से अच्छी मात्रा में उधार ले सकते हैं (मैंने उसके सभी पथ पार्सिंग तर्क उधार नहीं लिए क्योंकि ऐसा लग रहा था कि इसमें बाधाएं हो सकती हैं SkParsePath नहीं करता है और SkParsePath की तरह अधिक कुशल होना चाहिए क्योंकि इसकी आवश्यकता होगी केवल प्रत्येक ड्राइंग कमांड के लिए राउंड ट्रिप के बजाय पथ खींचने के लिए मूल पक्ष की एक राउंड ट्रिप)। मैं भी इसी तरह के कारणों से @matanlurey का उपयोग नहीं कर पाया।

देखें https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart , https://github.com/dnfield/flutter_svg (जो वर्तमान में दो SVGs को रेंडर करने में सक्षम है) उस प्रोजेक्ट में कैनवास में शामिल है), और https://github.com/dnfield/engine/tree/path_svg (जो वर्तमान में लोटी के लिए मेरे PathMeasure/PathMetrics संबंधित कार्य भी शामिल है)।

हाय @dnfield ,

यहां आपके प्रारंभिक कार्यान्वयन पर मेरा विचार है। मैं केवल इतना कह दूं कि मैं जो कुछ भी कहने जा रहा हूं उससे आपके उत्साह और कोडिंग की प्रगति पर कोई फर्क नहीं पड़ेगा। जितना अधिक आप बेहतर करते हैं, क्योंकि हम इसे बाद में हमेशा उपयोग कर सकते हैं।

मेरे पास जो समस्या है वह वास्तुशिल्प है और यही कारण है कि। UI को 60 फ़्रेम/सेकंड पर प्रतिक्रियाशील होने के लिए, UI को ब्लॉक करने से पहले प्रत्येक फ़्रेम में केवल ~16ms चलाने के लिए है। तो चलिए मान लेते हैं कि आधे का उपयोग स्पंदन द्वारा किया जाता है, जो हमारे एसवीजी पार्सर के लिए 8ms छोड़ देता है और किसी भी एसवीजी फ़ाइल को पार्स करने और उस अवधि में छवि उत्पन्न करने का कोई तरीका नहीं है चाहे आपके पास कितना भी शक्तिशाली फोन/टैबलेट हो। तो सबसे अच्छी बात यह है कि धीमे उपकरणों को लक्षित करना और एसिंक कोड है जो कई फ्रेम का उपयोग करके ऐसा करने में सक्षम है लेकिन कुंजी यह है कि प्रत्येक फ्रेम केवल 8ms तक चल सकता है और फिर उसे वापस आना होगा और अगले फ्रेम पर उठाना होगा।

तो आप डार्ट: एक्सएमएल का उपयोग करके एक्सएमएल को पार्स नहीं कर सकते क्योंकि यह एसिंक नहीं है, यह तब तक अवरुद्ध रहेगा जब तक कि पूरी फाइल पार्स न हो जाए। साथ ही छवि उत्पन्न करना async होना चाहिए क्योंकि आप 8ms में सब कुछ नहीं कर सकते। कोड को समय से पहले अनुकूलित करने का कोई मतलब नहीं है, हालांकि सबसे अच्छा कोड लिखें जिसे पढ़ा जा सकता है। मेरे पास एक योजना है जो काम करेगी लेकिन इसमें कुछ समय लगेगा इसलिए मैं चाहता हूं कि आप जैसे हैं वैसे ही जारी रखें क्योंकि मैं हमेशा आपका काम ले सकता हूं और बाद में इसका इस्तेमाल कर सकता हूं। मेरा डिज़ाइन वर्तमान छवि लोडिंग कार्यक्षमता (एसेट इमेज और नेटवर्क इमेज) में प्लग करता है और उपयोगकर्ता को केवल '.png' के बजाय '.svg' निर्दिष्ट करने की आवश्यकता होती है।

कार्लोस।

@cbazza सिर्फ एक विचार है: एक अलग में पार्सिंग किया जा सकता है। मुझे लगता है कि यूआई से अलग संदेश चैनलों के साथ संवाद करने में सक्षम होने के लिए कुछ काम किया गया था और कॉपी करने के बजाय संदर्भ द्वारा आइसोलेट्स के बीच डेटा पास करने के लिए (हालांकि स्थिति या प्रगति के बारे में निश्चित नहीं है)

@cbazza - धन्यवाद। मुझे नहीं लगता कि dart_xml इसके लिए सबसे अच्छा समाधान है, लेकिन यह काम करता है और ड्राइंग लॉजिक के आसपास कुछ प्रगति को सक्षम बनाता है (और मैं async XML पार्सर को लागू करने के लिए काम करते हुए इसे पूरी तरह से ब्लॉक नहीं करना चाहता था)। मैंने ImageProvider को लागू करना भी शुरू कर दिया, लेकिन मुझे लगता है कि यह एक कार्यान्वयन विवरण हो सकता है जिसे हम उपयोगकर्ताओं से अस्पष्ट कर सकते हैं।

मैं किसी भी तरह से इस एपीआई पर सेट नहीं हूं। लेकिन हम कम से कम एसवीजी ड्राइंग शुरू कर सकते हैं, और शायद अच्छे फोन पर साधारण लोगों का समर्थन कर सकते हैं।

क्या आप एक्सएमएल/एसवीजी रीडिंग/पार्सिंग एपीआई पर काम करने का इरादा रखते हैं?

@zoechi - हम अभी भी बेहतर मेमोरी उपयोग प्राप्त कर सकते हैं और स्ट्रीमिंग रीडर मॉडल के साथ शायद बेहतर पार्सिंग समय प्राप्त कर सकते हैं।

@zoechi हाँ मैंने आइसोलेट्स को देखा लेकिन आप केवल आदिम मान (शून्य, संख्या, बूल, डबल, स्ट्रिंग) और सूचियों और मानचित्रों को पास कर सकते हैं, न कि ऑब्जेक्ट्स और/या ऑब्जेक्ट पेड़, इसलिए एसिंक रूट बेहतर लग रहा था। एसिंक्स एक्सएमएल पार्सिंग का पता लगाने के बारे में एक और दिलचस्प बात यह है कि अवधारणाएं किसी भी एसिंक ट्री प्रोसेसिंग पर लागू होंगी, उदाहरण के लिए विजेट या एलिमेंट ट्री। यह उदाहरण के लिए रिएक्ट के फाइबर की तरह async सामंजस्य को सक्षम करेगा :)

@dnfield हाँ मैं async xml/svg पार्सर/प्रोसेसर पर काम कर रहा हूँ।

बस सोच रहा था, वेब-व्यू का उपयोग करके एसवीजी को प्रस्तुत करना एक विकल्प हो सकता है?

साधारण बटनों के लिए बहुत भारी और मुझे यकीन नहीं है कि वेबव्यू 60 फ्रेम/सेकंड परिवर्तनों को संभालने में सक्षम होगा। मेरा मतलब है कि मान लें कि हम आइकन को इधर-उधर घुमाते हैं या उदाहरण के लिए इसे स्केल करते हैं।

मैं आईओएस डेवलपर नहीं हूं, इसलिए अब मैं देख रहा हूं कि आईओएस 11 में वेक्टर संपत्तियों के लिए भी समर्थन है । यह एसवीजी नहीं है, बल्कि पीडीएफ है। पीडीएफ वेक्टर संपत्तियों का समर्थन करना आसान है?

नहीं। क्वार्ट्ज के आंतरिक रेंडरिंग सिस्टम के लिए पीडीएफ के साथ बहुत सारे ऐतिहासिक संबंध हैं, जिससे आईओएस डिवाइस पर ऐसा करना आसान हो जाता है। स्कीया एक पीडीएफ रेंडरर नहीं है, और फ़ाइल प्रारूप (आईएमओ) समर्थित है और क्या नहीं है (इसे ठीक करने के लिए अच्छी टूलिंग के साथ उपलब्ध नहीं है) के बारे में बहुत अस्पष्टता पेश करेगा।

पीडीएफ एसवीजी की तुलना में अधिक जटिल है और पीडीएफ/एक्स सबसेट (जो वेक्टर संपत्तियों के लिए उपयोग किया जाता है) को प्रिंटिंग के लिए डिज़ाइन किया गया है। मैं हालांकि स्पंदन पर पीडीएफ प्रतिपादन समर्थन देखना पसंद करूंगा लेकिन हमारे लिए एसवीजी से चिपके रहते हैं।

मैं svg (बिंदु, रेखा, वक्र, भरण, चाल) के मात्र वेक्टर ड्रायबल उपसमुच्चय से खुश हूँ। स्पंदन आरएडी के लिए अनुमति देता है और इसका लक्ष्य वास्तव में मल्टीप्लेटफार्म होना है (डेस्कटॉप आने के साथ) लेकिन अब ऐसा नहीं हो सकता है। Android और Apple दोनों प्लेटफॉर्म 60"+ 4HD स्क्रीन पर मौजूद हैं। वहां वेक्टर ग्राफिक्स होना जरूरी है।

पीएस क्षमा करें, लेकिन वीजी के बिना आपका (स्पंदन टीम) काम गायब हो जाएगा क्योंकि कोटलिन आईओएस सहित कई प्लेटफार्मों पर मूल रूप से काम कर रहा है। निश्चित रूप से कोटलिन मूल निवासी अभी भी बीटा में है लेकिन स्पंदन भी है। :(

@ohir कृपया बताएं कि आप क्रॉस प्लेटफॉर्म व्यू (एकल कोड) कैसे लिखेंगे जो कोटलिन मूल के साथ आईओएस और एंड्रॉइड दोनों पर काम करता है। जब तक आप प्रतिक्रिया देशी विजेट अमूर्तता का कोटलिन संस्करण बनाने का इरादा नहीं रखते हैं?

आइए इस बात को कम न समझें कि कोटलिन के मूल निवासी क्या करेंगे क्योंकि संभावनाएं अनंत हैं। मुझे Cocos2d-x का उपयोग करके स्पंदन जैसा कुछ बनाने वाले अपने प्रयोगों से स्पंदन मिला। वे इसका भी उपयोग कर सकते हैं और/या मूल निवासी और/या स्पंदन प्रतिक्रिया कर सकते हैं क्योंकि सब कुछ खुला स्रोत है और क्रॉस परागण के लिए उपलब्ध है :)

हाँ, पूरी तरह से सहमत हैं, कोटलिन प्यार और डेवलपर्स से अपनाना बहुत बड़ा है और क्रॉस प्लेटफॉर्म संकलन संभावनाओं को अंतहीन बनाता है। लेकिन आज मोबाइल क्रॉस प्लेटफॉर्म के लिए फ़्लटर बीटा और कोटलिन देशी बीटा के बीच तुलना व्यर्थ है।
वैसे भी, विषय से विचलित।

@lukaspili अब तक Android के लिए anko है। इसके लेआउट डीएसएल संबंधित प्लेटफॉर्म सबट्री में शामिल एपीको , लिंको और विंको* के साथ भी बरकरार रह सकते हैं। लेकिन यह स्पंदन वीजी मुद्दे के लिए ओटी है। [* अभी तक मौजूद नहीं है]।

सभी भावुक बातचीत के लिए धन्यवाद! हम इस मुद्दे को वेक्टर प्रारूपों और एपीआई के लिए उपयोग के मामलों और आवश्यकताओं पर केंद्रित रखना चाहते हैं। विषय पर बने रहने के लिए अग्रिम धन्यवाद! :)

एसवीजी का समर्थन करने और इसे कुछ टीबीडी स्पंदन वेक्टर प्रारूप के लिए रखने के लिए लोग इसे एक मुद्दे में विभाजित करने के बारे में क्या सोचते हैं?

यह मुझे समझ में आएगा; मूल मुद्दे को किसी प्रकार के स्पंदन-विशिष्ट वेक्टर प्रारूप के रूप में चित्रित किया गया है।

svg- जैसे समर्थन के लिए @cbazza हुर्रे। मेरे पास गैर-आइकन svgs का एक गुच्छा है जिसका उपयोग मैं मूल रूप से किसी ऐप के संपूर्ण UI को आकर्षित करने के लिए करता हूं। मैं उन्हें आपके पास कैसे भेजूं?

स्पंदन करने की कोशिश करना पसंद करेंगे लेकिन एक अरब पीएनजी उत्पन्न करना ऐप आकार को गंभीरता से ब्लोट करने और बदसूरत दिखने वाला है।

हां, फाइलों को देखने के लिए कृपया मुझे एक यूआरएल भेजें।

तो इस समय, इस मोर्चे पर, मैं फ़्लैटबफ़र आधारित दृष्टिकोण अपना रहा हूँ। मैं एक फ्लैटबफर स्कीमा को परिभाषित करने पर काम कर रहा हूं जो वेक्टर ड्राइंग कमांड को कैप्चर कर सकता है - स्कीया पथों को कैप्चर करने के तरीके से कम या ज्यादा।

मैं इसे एसवीजी के साथ सेमी-इंटरऑपरेबल देख सकता था (उदाहरण के लिए एक एसवीजी -> फ्लैटबफर रूपांतरण उपकरण, या एंड्रॉइड वेक्टर ड्रॉएबल एक्सएमएल -> फ्लैटबफर, जो कई एसवीजी उपयोग मामलों को कवर कर सकता है), और बहुत से प्रदर्शन हिट से बचें हम एसवीजी का सामना करना पड़ेगा (एक्सएमएल पार्सिंग स्ट्रीमिंग की कमी, एसवीजी पथ डेटा को पार्स करने की आवश्यकता है और फिर इसे बिट द्वारा मूल बिट पर भेजें)। मैं एसवीजी प्रारूप की तुलना में छोटी बाइनरी फाइलें भी तैयार करने में सक्षम हूं (हालांकि यह देखा जाना बाकी है कि यह कितना अच्छा होगा)।

किसी दिए गए SVG में कौन सी विशेषताएँ समर्थित नहीं हैं (उदाहरण के लिए "ForeignElements इस प्रारूप द्वारा समर्थित नहीं हैं") के बारे में रूपांतरण टूलिंग में पहले से अधिक स्पष्टता देना संभव होना चाहिए।

फ्लैटबफ़र पार्सिंग बिट डार्ट या सी ++ में किया जा सकता है - डार्ट में एक बात यह है कि कैनवास पर पथ बनाने और ड्राइंग के लिए स्की को कमांड बैच करने का कोई तरीका अभी भी अच्छा होगा।

एक संभावित रूप से बहुत आसान समाधान है जो एसवीजी से स्की नोड ऑपरेशंस का संकलन-समय पार्सिंग और डाइजेस्ट करना है ... यह एसवीजी के रनटाइम पार्सिंग को पूरी तरह खत्म कर देगा और इंटरमीडिएट बफर के बरकरार मोड कैशिंग की अनुमति देगा।

@sandrobilbeisi आपका मतलब https://github.com/amirh/flutter/commit/69de4bbf3177d9766a386c55b27a12619da43a05 जैसा है?

यह उल्लेखनीय है ... और विटूल भी है https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart

लेकिन मैं एक निर्माण कदम के रूप में और अधिक सोच रहा था जैसे कि एक एक्सकोड आईओएस डिलिवरेबल्स के लिए एसवीजी संपत्तियों के साथ उपयोग करता है

@sandrobilbeisi क्या आपका मतलब संकलन समय के दौरान svgs से बिटमैप बनाना है?

BTW Xamarin पैकेज ffimageloading रेंडर किए गए बिटमैप्स को कैश करता है इसलिए केवल एक बार रेंडरिंग। यह नेटवर्क छवियों को भी कैश करता है और छवियों का आकार बदलता है जो इसे वास्तव में तेज़ बनाता है

बिटमैप नहीं, लेकिन स्की जो मूल रूप से < कैनवास > . के लिए एक वेक्टर ग्राफिक्स इंजन है
https://skia.org/ ( ps एक दर्जन साल पहले Google द्वारा अधिग्रहित किया गया था: http://www.satine.org/archives/2007/03/05/the-skia-source-code-dilemma/ )

आपका मतलब एसवीजी को स्की छवि प्रारूप में परिवर्तित करना है?

हां

@cbazza SVG परीक्षण फ़ाइलों का लिंक: https://github.com/slingshotapp/artwork

क्या परियोजना स्तर पर विटूल चलाने का कोई तरीका है? मैं जेनरेट की गई फ़ाइल बना सकता हूं लेकिन इसे बहुत से निजी वर्गों तक पहुंच की आवश्यकता है जो मुझे मेरी परियोजना में .g.dart जोड़ने से रोकते हैं।

<flutter>/dev/tools/vitool : #dart bin/main.dart --asset-name=_$hello --output=here.g.dart ./test_assets/horizontal_bar_relative.svg . पर टूल का जिक्र करते हुए

@emilieroberts धन्यवाद लेकिन वे फ़ाइलें एसवीजी प्रारूप में नहीं हैं बल्कि कस्टम एंड्रॉइड वेक्टर प्रारूप पर हैं जो एसवीजी के समान ही है।

@cbazza उफ़, वास्तव में - अधिकांश svgs अब वहाँ हैं :)

@cbazza क्या आप स्पष्ट कर सकते हैं कि कस्टम एंड्रॉइड वेक्टर के साथ आपका क्या मतलब है? एंड्रॉइड वेक्टर ड्रॉबल्स के विपरीत, उनके पास <svg टैग है।

इस समय विटूल के साथ जो कुछ भी किया जा रहा है वह आश्चर्यजनक है, लेकिन मुझे कहीं भी दस्तावेज़ीकरण का कोई निशान नहीं मिला। मैं इसे AnimatedIcons.arrow_menu के साथ एक उदाहरण लिख सकता हूं, लेकिन मैं यह भी जानना चाहता हूं कि बाहरी स्पंदन एसडीके से संपत्ति से ऐसा करने के लिए क्या करना होगा।

@fmatosqg आप सही हैं, कोड जो कि vitool द्वारा उत्पन्न एनिमेशन को चलाने के लिए उपयोग किया जाता है, वह ढांचे के लिए निजी है। इसका कारण यह है कि स्पंदन के लिए एक अच्छा वेक्टर प्रारूप क्या होगा (जैसा कि इस मुद्दे में ट्रैक किया गया है) के बारे में अभी भी खुले प्रश्न हैं, और मैं एक सार्वजनिक एपीआई से बचना चाहता हूं जो किसी विशिष्ट प्रारूप का समर्थन करता है (जैसा कि उस प्रारूप के लिए प्रतिबद्ध होगा यदि हम भविष्य में बदलाव को तोड़ना नहीं चाहते हैं)।
AnimatedIcon के लिए वर्तमान एपीआई सतह हमें आंतरिक रूप से ढांचे में विटूल द्वारा उत्पन्न फाइलों का उपयोग करने की अनुमति देती है, और फिर भी किसी भी क्लाइंट को तोड़े बिना अंतर्निहित कार्यान्वयन और वेक्टर प्रारूप को बदलने में सक्षम है।

यदि आप विटूल के साथ फाइलें बनाना चाहते हैं और इसे अपने प्रोजेक्ट में उपयोग करना चाहते हैं, तो आप इसे packages/flutter/lib/src/material/animated_icons से कोड कॉपी करके और इसे अपने प्रोजेक्ट के हिस्से के रूप में शामिल करके कर सकते हैं (यह भी गारंटी देता है कि आपकी परियोजना टूट नहीं जाएगी यदि हम एनिमेटेड आइकन द्वारा उपयोग की जाने वाली मशीनरी को बदलते हैं)।

असुविधा के लिए खेद है और आशा है कि हमें जल्द ही एक बेहतर समाधान मिलेगा।

मुझे यह विचार पसंद है, खासकर अगर https://github.com/flutter/flutter/issues/13834 आगे बढ़ता है। मेरा मानना ​​​​है कि ऐसी चीज एक मोनोलिथिक एसडीके का हिस्सा नहीं होनी चाहिए, लेकिन विशेष रूप से चिंतित नहीं है अगर यह आधिकारिक या सामुदायिक पैकेज है।

बड़े G पर किसी के द्वारा शाइनी (गो डेस्कटॉप फ्रेमवर्क) के लिए गढ़े गए svg के सबसेट के लिए एक कॉम्पैक्ट प्रारूप है । इसका द्विआधारी प्रतिनिधित्व और 100 बाइट्स के तहत डिफ़ॉल्ट एंड्रॉइड लॉन्चर आइकन आकार ला सकता है। जैसा कि धागे में ऊपर बताया गया है - और आईएमएसओ - ड्राइंग वैक्टर स्की का कर्तव्य होना चाहिए, जिसमें स्पंदन सबसे कॉम्पैक्ट प्रतिनिधित्व उपलब्ध है। यह res/ svg फ़ाइलों को आंतरिक प्रारूप में संकलित करने का टूलिंग कर्तव्य है।
[ @amirh पुन: प्रश्न खोलें कि एक अच्छा वेक्टर प्रारूप क्या होगा ]

तो FWIW, flutter_svg में मैंने कोड तैयार किया है जैसे कि सभी चित्र वास्तव में मध्यवर्ती वस्तुओं द्वारा किए जाते हैं। एसवीजी संबंधित कार्य मूल रूप से उन वस्तुओं के लिए एसवीजी का मानचित्रण कर रहा है। उस मध्यवर्ती प्रारूप को पूरी तरह से स्थिर करने के लिए अभी भी काम करना बाकी है (उदाहरण के लिए, मैंने पाठ समर्थन शुरू कर दिया है लेकिन यह अभी बहुत खराब है)।

मैंने फ्रेमवर्क में एंड्रॉइड वेक्टर ड्रॉएबल्स के लिए समर्थन पर पोर्ट करना शुरू कर दिया है (बाहरी रंग और शैली संदर्भ आदि के लिए माइनस सपोर्ट, और अभी तक क्लिप पथ या शायद कुछ अन्य सुविधाओं का समर्थन नहीं कर रहा है)। इस तरह से भी, या वास्तव में किसी अन्य प्रारूप में शाइनी का समर्थन करना पूरी तरह से संभव होना चाहिए। मुझे इस समय इसके लिए एसवीजी के माध्यम से काम करना पसंद है क्योंकि यह समर्थन करने के लिए बहुत सारे दिलचस्प मामलों को कवर करने में मदद करता है, इसलिए अभी के लिए मेरा प्राथमिक ध्यान यही है।

इस धागे को पढ़ने के बाद - और JSX समर्थन के बारे में एक लंबा - मैं यह सोचने में मदद नहीं कर सकता कि एक शासन समस्या मौजूद है। फ़्लटर टीम को एक हज़ार अलग-अलग दिशाओं में खींचे जाने का जोखिम है क्योंकि डेवलपर के कोलाहल के लिए _they_ क्या महत्वपूर्ण है। शायद स्पंदन को अपाचे की तरह "इनक्यूबेटर" परियोजनाओं को स्थापित करना चाहिए। अनुरोधित सुविधाओं को प्लगइन्स द्वारा एक ओपन-सोर्स तरीके से कार्यान्वित किया जाता है, संभवतः फ़्लटर टीम के योगदान के साथ। यदि प्लगइन्स पर्याप्त समर्थन, प्रभावकारिता और लोकप्रियता प्राप्त करते हैं, तो वे कोर स्पंदन ढांचे में शामिल करने के लिए उम्मीदवार बन जाते हैं।

मुझे लगता है कि यह सबसे मुखर डेवलपर्स को छाती का सहारा लेने के बजाय अपना "कोड जहां मुंह है" डालने देगा- और यहां प्रदर्शन पर ब्रो-बीटिंग, और कोर इंजीनियरिंग पर ध्यान केंद्रित करने के लिए फ़्लटर टीम को और अधिक स्वतंत्र छोड़ देगा।

मैं सम्मानपूर्वक असहमत हूं। यदि आप बकेट 5 जैसे मील के पत्थर को देखते हैं तो आपको पता चल जाएगा कि टीम किस पर काम कर रही है और यदि आप बकेट 6 पर जाते हैं तो आप जानते हैं कि वे क्या प्राथमिकता मानते हैं। इसके अलावा, आप जान सकते हैं कि यदि आप सड़क के नीचे अन्य मील के पत्थर को देखते हैं तो वे क्या जरूरी नहीं समझते हैं।

इसके अलावा स्पंदन कोर में कुछ जोड़ने का कारण "मैं एक प्लगइन कर सकता हूं और यह सभी के लिए काम करता है और हर कोई इसे चाहता है" से अधिक होना चाहिए। यह एक प्लगइन बनाने का एक कारण है, लेकिन इस रेपो या अन्य स्पंदन रेपो में जोड़ने के लिए पर्याप्त नहीं है।

चीजों का एक उदाहरण जो प्लगइन्स नहीं होना चाहिए: चीजें जिन्हें @dnfield ने इंजन में जोड़ा ताकि वह अपने स्वामित्व वाले प्लगइन से लाभ उठा सकें और उपयोग कर सकें। इस तरह के प्लगइन के पास सभी सुविधाओं को करने का कोई मौका नहीं होगा यदि उन्हें इंजन में नहीं जोड़ा गया था।

मुखर होना महत्वपूर्ण है, लेकिन यह कभी गारंटी नहीं देगा कि यह चलेगा। जहां मुंह है वहां कोड डालना भी महत्वपूर्ण है लेकिन फिर भी पर्याप्त नहीं है। इस परियोजना में बहुत पारदर्शिता है और वे स्पष्ट रूप से सुनते हैं कि देव क्या कहते हैं, लेकिन यह लोकतंत्र नहीं है और इसका मतलब यह नहीं है कि परिणामों के बारे में तर्क किए बिना लोकप्रिय वोट जीत जाएगा।

हां, कृपया चिंता न करें कि फ़्लटर के ढांचे पर काम करने वाले डेवलपर्स बग पर चर्चा से विचलित हो जाएंगे। :-) हम चर्चाओं को पढ़ते हैं, और हम सभी की राय के बारे में बहुत परवाह करते हैं, लेकिन दिन के अंत में हमारे पास स्पष्ट मार्गदर्शक सिद्धांत हैं और हम केवल सबसे तेज आवाज पर प्रतिक्रिया नहीं करने जा रहे हैं। हम यह निर्धारित करने के लिए सावधानीपूर्वक बाजार विश्लेषण करते हैं कि समग्र रूप से समुदाय किस चीज की परवाह करता है।

दिलचस्प बातचीत जो मुझे एक साधारण प्रश्न के साथ छोड़ देती है। फ़्लटर टीम कैसे अनुशंसा करती है कि हम फ़्लटर में डिज़ाइन चरण (एसवीजी) से वेक्टर ग्राफिक्स पर जाएं?

@lukepighetti आप https://github.com/dnfield/flutter_svg आज़मा सकते हैं और जाँच सकते हैं कि यह आपको कितनी दूर तक ले जाता है।

व्यक्तिगत रूप से मैं स्पंदन में एसवीजी फाइलों के लिए पेश किए गए समाधान से खुश नहीं हूं। मैंने flutter_svg पैकेज का उपयोग किया है और मैं इससे खुश नहीं हूं।

मानक पुस्तकालय में मेरी राय में एसवीजी समर्थन को मूल रूप से समर्थित करने की आवश्यकता है। अगर हम डेस्कटॉप ऐप्स और वेबसाइटों जैसी बड़ी स्क्रीन पर फ़्लटर का उपयोग शुरू करने जा रहे हैं तो यह बहुत जरूरी है।

@socialmammoth क्या आप विस्तार से बता सकते हैं कि आप कौन सी कमियां देख रहे हैं?

एक बात जिस पर मैं कुछ समय से विचार कर रहा था कि क्या .skp (SKIAPICT) प्रारूप का समर्थन करना उचित होगा। मुझे लगता है कि इसे सीधे नहीं करने के अच्छे कारण हैं - प्रारूप को संस्करण से संस्करण तक स्थिर होने की गारंटी नहीं है क्योंकि स्कीया बड़ा है।

हालांकि, इसमें कुछ दिलचस्प गुण हैं - विशेष रूप से, एसकेपी (शायद एक प्रस्तुत एसवीजी) उत्पन्न करने के लिए क्रोम/क्रोमियम प्राप्त करना संभव है, और यह बहुत संभावना है कि हम वास्तव में आवश्यक अधिकांश या सभी स्कीया ड्राइंग कमांड का समर्थन करते हैं SKPs के विशाल बहुमत को प्रस्तुत करते हैं।

मैं एसवीजी प्लगइन के लिए कोड-जेन प्रकार का समाधान बनाने की योजना बना रहा हूं, ताकि आप एसवीजी से डार्ट/फ्लटर कोड उत्पन्न कर सकें। मुझे लगता है कि इस बिंदु पर एसकेपी से डार्ट निर्माण प्रक्रिया की जांच करना शायद अधिक दिलचस्प होगा - स्पंदन एसवीजी के लिए लिखे गए कुछ कोड को ढांचे में पोर्ट किया जा सकता है (उदाहरण के लिए RawPicture और संबंधित बुनियादी ढांचे, जो मोटे तौर पर एक RawImage से मेल खाती है), और हम कुछ ऐसा तार-तार कर सकते हैं जो एक एसकेपी का आउटपुट लेगा (शायद क्रोम द्वारा प्रदान किए गए एसवीजी से उत्पन्न होता है, जो वैसे भी एसवीजी प्रतिपादन के लिए काफी स्वर्ण मानक है)। टूलिंग बनाना संभव होना चाहिए जो एक एसवीजी लेगा, इसे एसकेपी को प्रस्तुत करने के लिए हेडलेस क्रोमियम का आह्वान करेगा, और फिर एसकेपी को कुछ डार्ट फ़ाइल में परिवर्तित कर सकता है जो फ़्लटर रनटाइम पर प्रस्तुत कर सकता है।

एक बड़ा क्षेत्र जो इसे हल नहीं करता है वह गतिशील रूप से रनटाइम पर एक वेक्टर ग्राफ़िक लोड कर रहा है (उदाहरण के लिए SvgPicture.network ), लेकिन मुझे फीडबैक में दिलचस्पी है कि यह उस सीमा के साथ भी एक सार्थक/स्वीकार्य समाधान होगा या नहीं।

मैं यह भी इस विश्वास के साथ कहता हूं कि इस समय, हमें स्पंदन में एसवीजी के लिए "मूल" समर्थन कभी नहीं मिलेगा। यह आंशिक रूप से है क्योंकि एसवीजी के पास बहुत अधिक सामान (एक्सएमएल, सीएसएस, बाहरी संपत्ति लाने की क्षमता) है जो ब्राउज़र/एचटीएमएल रेंडरिंग सॉफ़्टवेयर के बाहर लागू करने के लिए गैर-तुच्छ हैं और हम जिस सॉफ़्टवेयर की कोशिश कर रहे हैं उसमें बहुत अधिक ब्लोट जोड़ देगा नीचे झुकना। यह आंशिक रूप से भी है क्योंकि ढांचे में कोई बड़ा बदलाव किए बिना एसवीजी का थोड़ा सा कार्यान्वयन करना पूरी तरह से संभव है - हालांकि कुछ चीजें ( filterEffect s और textPath s विशेष रूप से अभी) शायद इंजन में कुछ और ट्विक्स का लाभ उठाएं।

मुझे लगता है कि एसवीजी को सीधे नेटवर्क से लोड करने में सक्षम होना एक बड़ा लाभ है, भले ही इसका मतलब है कि हम केवल प्रारूप की कार्यक्षमता के सबसेट का समर्थन करते हैं।

स्पंदन-विशिष्ट वेक्टरियल प्रारूप होने से ऐसा लगता है कि एंड्रॉइड वेक्टर ड्रावेबल्स के साथ क्या कर रहा है, जबकि यह ठीक काम करता है, इसका मतलब यह भी है कि एसवीजी के लिए पहले से मौजूद बहुत सारे टूलिंग से लाभ नहीं हो सकता है। यह सभी प्रारूप रूपांतरणों के कारण डिज़ाइन को पुनरावृत्त करना भी अजीब बनाता है।

मैं मूल रूप से स्पंदन समर्थन एसवीजी देखना चाहता हूं क्योंकि 2018 में फ्रंट एंड देव अपने ढांचे से यही उम्मीद करते हैं। मैं चाहता हूं कि फ्रंट एंड देवों को स्पंदन सुलभ हो, क्योंकि मैं पारिस्थितिकी तंत्र को विकसित करना चाहता हूं।

@dnfield

.skp (SKIAPICT) प्रारूप।

आईएमएचओ दिलचस्प दृष्टिकोण। लेकिन तब स्पंदन टूलींग (कम से कम AS में) को रूपांतरण के साथ मूल रूप से निपटने की आवश्यकता होती है। डिज़ाइनर कुछ हद तक वर्तमान एंड्रॉइड के वेक्टर-ड्राएबल आयातों द्वारा लगाए गए प्रतिबंधों के लिए उपयोग किए जाते हैं, इसलिए वे निश्चित रूप से डॉस और डॉनट्स के अन्य सेट से निपटने में सक्षम होंगे।

आकस्मिक डेवलपर के लिए मैनुअल को पढ़ना चाहिए: " अपने svg चित्र यहां छोड़ें, यहां एनोटेट करें, इच्छा पर उपयोग करें। यदि आपका svg समर्थित SVG उपसमुच्चय का पालन नहीं करता है (यहां देखें) संकलक या विश्लेषक ( flutter analyze ) बताएगा आप अपने svg में क्या गलत है "। या कुछ इस तरह का।

@dnfield

उत्पन्न करने के लिए क्रोम/क्रोमियम प्राप्त करें

PoC और परीक्षण के लिए अच्छा है, लेकिन वास्तविक समाधान IMHO को इतनी बड़ी निर्भरता की आवश्यकता नहीं हो सकती है - और एक जिसे CI मध्य चरण के रूप में स्क्रिप्ट करना कठिन है। बेशक बीटा में और फिर दूसरे 'कठिन तरीके' के रूप में यह ठीक हो सकता है - उदाहरण के लिए। आसान एनिमेटेड ड्राइंग प्राप्त करने के लिए जिसे skPicture अनुमति देता है। मैं गलत हो सकता हूँ। चूंकि डिजाइनरों के पास आमतौर पर उनके लैपटॉप फ्लैप के नीचे ब्राउज़र के साथ एक बड़ी बाल्टी होती है। बहरहाल, ध्यान रखें कि कलाकृति अक्सर उत्परिवर्तित होती है। न केवल प्रोटोटाइप चरण में बल्कि लॉन्च के समय के रूप में भी और देव बग शिकार बुखार में हैं।

[अर्थात। हमें या तो अनुरूप svg आयात के साथ स्पंदन उपकरण सौदे की आवश्यकता है या हमें एक ऐसे तरीके की आवश्यकता है जहां क्रोमियम पूरी तरह से डिजाइनर के हाथों में हो। डेवलपर का नहीं।]

पुनश्च. Launcher_icons पैकेज तरीका शुरुआत में कर सकता है: flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps ।

-- मेरी 2

@कचपा

एसवीजी को सीधे नेटवर्क से लोड करने में सक्षम होना

यह एक अलग विशाल पैकेज के लिए एक काम है जो सत्यापन और कामकाज से निपटेगा
संभावित असंगतियों और निर्माता की विचित्रताओं के आसपास।
डेवलपर के आपूर्ति किए गए वेक्टर प्रारूप को आकर्षित करने के लिए पहले इंजन प्राप्त करें जो "नेटवर्क से एसवीजी लोड करें" पैकेज निश्चित रूप से उपयोग करेगा। :)

बस स्पष्ट होने के लिए @cachapa और @ohir - flutter_svg _already_ नेटवर्क पर एक SVG लोड करने का समर्थन करता है ( SvgPicture.network )। हालांकि, वह पैकेज कभी भी एसवीजी विनिर्देश की संपूर्णता का समर्थन नहीं करेगा - लक्ष्य वास्तव में केवल अधिकांश एसवीजी को प्रस्तुत करने के लिए पर्याप्त विनिर्देश का समर्थन करना है। यह पहले से ही ऐसा करता है, इस बिंदु पर प्रमुख अपवाद fliterEffect s (इसलिए कोई धुंधला, रंग फ़िल्टर, आदि नहीं) और टेक्स्ट से संबंधित बहुत सारे समर्थन हैं - लेकिन कुछ अन्य हैं ( marker s समर्थित नहीं हैं, प्रमाणित प्रकार के xlink:href संदर्भ अभी भी समर्थित नहीं हैं)। कुछ ऐसे मुद्दे भी हैं जिनका मैं जानबूझकर समर्थन नहीं कर रहा हूँ, जैसे पूर्ण CSS विनिर्देश, स्क्रिप्टिंग और अन्तरक्रियाशीलता।

@lukepighetti मुझे लगता है कि उम्मीद केवल वेब आधारित फ्रंट एंड डेवलपर्स के साथ ही मौजूद है। क्यूटी एसवीजी का समर्थन करता है, लेकिन केवल एक सीमित उपसमुच्चय। गनोम librsvg के साथ थोड़ा और समर्थन करता है, लेकिन फिर से इसमें कुछ समस्याएं हैं (और लिनक्स वातावरण के बाहर उपयोग करना वाकई मुश्किल है)। मैं यह देखने के लिए उत्साहित हूं कि resvg के साथ क्या होता है, लेकिन मुझे किसी भी जीयूआई पुस्तकालय के बारे में पता नहीं है जो इसे एकीकृत कर रहा है।

@dnfield मैं आपके काम की आलोचना नहीं करना चाहता क्योंकि आपने बहुत अच्छा काम किया है और इसके लिए मैं आपको बहुत धन्यवाद देता हूं। मैं बस निराश हूं कि रंग अपेक्षा के अनुरूप काम नहीं करता है। मुझे अपना रंग खुद चुनना था, मैं कलाकार नहीं हूं, मैं भी रंगहीन हूं।

स्पंदन को उसी तरह एसवीजी का समर्थन करने की जरूरत है जैसे आधुनिक ब्राउज़र करते हैं। यह बहुत जरूरी है। हमें बिना किसी संशोधन के सीधे वेब पेज से कॉपी या आयात की गई संपत्तियों का उपयोग करने में सक्षम होना चाहिए।

स्पष्ट रूप से भगवान का शुक्र है कि कम से कम एक पैकेज है, लेकिन हमें रंग चाहिए, हमें प्रभाव चाहिए, अगर प्रदर्शन एक मुद्दा है तो लोगों के लिए सुविधाओं को बंद करने के लिए इसे वैकल्पिक बनाने के लिए उन्हें सुविधाओं को चालू करने के लिए मजबूर न करें।

हमें एसवीजी के लिए पूर्ण विशिष्ट समर्थन की आवश्यकता है। मैं @lukepighetti से सहमत हूं। हमिंगबर्ड के साथ, यह एक जरूरी है, या वेब देव स्पंदन पर हंसेंगे और इसे एक कठिन पास देंगे।

यहां तक ​​कि @yjbanov ने अपने लेख में इसका उल्लेख यहां किया है: https://medium.com/flutter-io/hummingbird-build-flutter-for-the-web-e687c2a023a8

चूँकि @dnfield ने 'resvg' का उल्लेख किया है, @SocialMammoth शायद flutter_svg को पूर्ण svg समर्थन के बजाय 'SVG स्थिर' समर्थन का लक्ष्य रखना चाहिए:
http://www.w3.org/TR/SVG11/feature#SVG -स्थैतिक,
जो मुझे लगता है कि सभी को खुश करना चाहिए।

यहां तक ​​​​कि क्रोम सभी एसवीजी सुविधाओं का समर्थन नहीं करता है और विशेष रूप से दाएं से बाएं पाठ प्रतिपादन छोटी है (पिछले कुछ वर्षों में बिना किसी प्रगति के)। दूसरे शब्दों में, मुझे नहीं लगता कि पूर्ण एसवीजी समर्थन यथार्थवादी है। एसवीजी-स्थैतिक एक उचित उपसमुच्चय प्रतीत होता है। Flutter_svg में मुझे टेक्स्ट हैडलिंग (पथ पर टेक्स्ट सहित), फिल्टर और मास्क की याद आती है। कुछ इस तरह के निर्माण के लिए स्पंदन में समर्थन प्राप्त करना अच्छा होगा https://drifted.in/horologium-app/

@सोशलमैमथ

स्पंदन को उसी तरह एसवीजी का समर्थन करने की जरूरत है जैसे आधुनिक ब्राउज़र करते हैं

नहीं, स्पंदन ऐप्स को दुबला होना चाहिए। यह मुद्दा सभी एसवीजी से निपटने के लिए सर्वशक्तिमान पैकेज के बारे में नहीं है, यह स्पष्ट रूप से कहता है "एक वेक्टर ड्रॉएबल प्रारूप का समर्थन करें" ( एसवीजी का समर्थन नहीं)। लक्ष्य, जैसा कि मैं इसे समझता हूं, अब तक सभी स्पंदन ऐप्स को बिटमैप संपत्तियों से जितना संभव हो सके छुटकारा पाना है। और वह इंजन स्तर पर। @dnfield ने पैकेज के माध्यम से बहुत अच्छा काम किया। अब समय आ गया है कि डार्ट से बिना स्पंदन (स्किया) इंजन या ऐप के ही कुछ वेक्टर ग्राफिक्स उपलब्ध कराएं। उस लक्ष्य के लिए .skp का उपयोग एक अच्छा विकल्प प्रतीत होता है। यह पहले से ही एंड्रॉइड के वेक्टर-ड्रॉएबल से अधिक की अनुमति देता है और यह पहले से ही इंजन में है। डिजाइनर इसके फीचर सेट में समायोजित होंगे।

@ohir मुझे लगता है कि हम तब असहमत हैं। एक फ्रंट-एंड फ्रेमवर्क जो एसवीजी फाइलों का समर्थन नहीं करता है, वास्तव में एक बुरा मजाक है।

ठीक है, मुझे नहीं लगता कि स्पंदन को svg उपयोगी होने की आवश्यकता है, लेकिन यह अच्छा होगा। और यदि svg नहीं है, तो कुछ प्रारूप की तुलना में जो आपके विशिष्ट वेक्टर ग्राफिक्स एप्लिकेशन से प्राप्त करना आसान है।

मूल रूप से एसवीजी यहां उपयोग करने के लिए मानक वेक्टर प्रारूप है लेकिन हम एसवीजी की हर सुविधा के लिए समर्थन की उम्मीद नहीं कर सकते। लक्ष्य हमेशा विशिष्ट वेक्टर ग्राफिक्स अनुप्रयोगों से वेक्टर संपत्ति आयात करने के लिए न्यूनतम समर्थन करना रहा है। कौन से वेक्टर ग्राफिक्स एप्लिकेशन .skp पढ़ और लिख सकते हैं?

यदि कोई वेक्टर प्रारूप पर्याप्त रूप से सर्वव्यापी है तो मेरा परीक्षण यह है कि यह Adobe Illustrator, Affinity Designer और Inkscape में उपलब्ध है। जहां तक ​​​​मुझे पता है कि एसवीजी बहुत ज्यादा छोड़ देता है। और मैं मानता हूं कि हमें हर एसवीजी फीचर की जरूरत नहीं है। बस बुनियादी पथ स्ट्रोक और भरण ठीक है।

मैं इसे अधिकार के साथ नहीं कह सकता, लेकिन मुझे संदेह है कि एसवीजी के एक सबसेट को लागू करना आसान होगा, इससे वेक्टर ग्राफिक्स अनुप्रयोगों को .skp का समर्थन करने के लिए राजी करना होगा?

@lukepighetti : डैन का विचार इंजन के आंतरिक प्रारूप का उपयोग करना है। इस समाधान का सार एसवीजी को उस प्रारूप में परिवर्तित करना है जिसे इंजन समझता है। इससे कोई फर्क नहीं पड़ता कि इंकस्केप इस प्रारूप को तब तक जानता है जब तक कोई व्यवहार्य कनवर्टर मौजूद है।

मैं कल संदेह में था, लेकिन आज, कुछ शोध के बाद, मुझे लगता है कि क्रोम ऑटोमेशन अच्छी तरह से समर्थित है। यदि हेडलेस क्रोम का उपयोग रेंडरिंग प्रॉक्सी के साथ किया जा सकता है तो इसे svg->skp कनवर्टर भी बनाया जा सकता है। थोड़ा भारी, लेकिन किफायती। कम लटकने वाला फल वास्तव में, @dnfield :)।

यह सब लगभग तीन साल पहले @Hixie द्वारा निर्धारित लक्ष्यों के साथ अच्छी तरह से फिट बैठता है।

अगर मैं गलत हूं तो @dnfield कृपया मुझे सुधारें।
मुझे लगता है कि .skp मूल रूप से स्कीया पिक्चर के लिए बाइनरी प्रारूप है।

यह देखते हुए कि डार्ट: यूआई में स्कीया पिक्चर के लिए एक रैपर भी है जिसे डार्ट भूमि से उत्पन्न किया जा सकता है, क्या इन चित्रों की सामग्री में विभिन्न स्की क्षमताएं नहीं होंगी? मूल रूप से क्रोम से एक सभी स्की कार्यक्षमता का उपयोग करेगा, जबकि डार्ट से एक: ui नहीं होगा (फ्लटर इंजन के माध्यम से जो उपलब्ध कराया गया था उससे सीमित)? 'प्रदर्शन' तर्क के लिए अजीब तरह का, है ना? स्पंदन इंजन और डार्ट: ui सभी स्की को हटा देता है जिसे धीमा समझा गया था (प्रदर्शन संख्या दिखाए बिना) लेकिन फिर आप उस सभी का उपयोग कर सकते हैं यदि यह क्रोम द्वारा उत्पन्न .skp फ़ाइल के माध्यम से आता है?

एक और बात, .skp का उपयोग करते समय आप किसी आइकन के रंग कैसे निर्दिष्ट करेंगे, उदाहरण के लिए यदि आइकन 2 रंगों या अधिक का उपयोग करता है?

पुराने तर्क के बारे में कैसे कि फ़्लटर में डार्ट का उपयोग करके आप प्रत्येक पिक्सेल पर नियंत्रण रखते हैं? मेरे लिए flutter_svg पैकेज 'एसवीजी स्टेटिक' का समर्थन करने का रास्ता है क्योंकि यह डार्ट भूमि में भविष्य के नवाचार को सक्षम करेगा। डार्ट को छोड़कर और सी ++ को इसे संभालने देने से ऐसा लगता है कि डार्ट इसे हैक नहीं कर सका।

स्की एसवीजी का समर्थन करता प्रतीत होता है। स्पंदन सीधे एसवीजी समर्थन क्यों प्रदान नहीं करता है?

मैं जो कह सकता हूं उससे फ़्लटर टीम स्की पैकेज का आकार जितना संभव हो उतना छोटा रखना चाहती है। मुझे नहीं पता था कि स्की एसवीजी का समर्थन करता है, लेकिन अगर ऐसा होता है, तो वह कम लटकने वाला फल है। एक नोट के रूप में, फ़्लटर के लिए लोटी समर्थन जोड़ने पर एक और मुद्दा है क्योंकि स्कीया इसका समर्थन करता है।

स्की एसवीजी से चित्र आयात करने का समर्थन नहीं करता है, लेकिन एसवीजी बनाने के लिए कुछ प्रयोगात्मक समर्थन है (जो यहां उतना उपयोगी नहीं है)।

और हाँ, पैकेज का आकार एक चिंता का विषय है।

कृपया यदि आप एसवीजी समर्थन मांगना चाहते हैं तो देखें: https://github.com/flutter/flutter/issues/15501

यह बग विशेष रूप से एसवीजी का समर्थन किए बिना वेक्टर ग्राफिक्स का समर्थन करने के बारे में है।

उन लोगों के लिए जो वेक्टर ग्राफिक्स प्रारूप में दिलचस्प हैं, मैं आपके उपयोग के मामलों के बारे में उत्सुक हूं।

मुझे अब तक इनके बारे में पता है:

• प्रतीक। स्थिर छवियां जिन्हें गतिशील रूप से पुन: रंगने की आवश्यकता हो सकती है (उदाहरण के लिए अक्षम होने पर धूसर हो जाती है), और लक्ष्य रेंडर आकार के आधार पर विवरण के विभिन्न स्तरों की आवश्यकता हो सकती है। पाठ होने की संभावना नहीं है।

• एनिमेटेड आइकन: ऊपर वर्णित दो आइकन, और एक से दूसरे में निर्बाध रूप से संक्रमण करने का विवरण।

• पृष्ठभूमि: छवियां जो स्क्रीन से बहुत बड़ी हो सकती हैं, शायद लंबन के साथ दिखाई जा सकती हैं; आकार, ढाल और छाया के साथ आम तौर पर सरल दृश्य, पाठ होने की संभावना नहीं है।

क्या ऐसे अन्य उपयोग के मामले हैं जो वेक्टर ग्राफिक्स के लिए आपकी आवश्यकता को प्रेरित करते हैं? कृपया उनका वर्णन यहाँ करें। धन्यवाद।

एकल ग्राफ़िक के साथ कई रिज़ॉल्यूशन का समर्थन करना, विशेष रूप से उच्च रिज़ॉल्यूशन स्क्रीन के लिए फ़ॉरवर्ड संगतता के साथ

मेरा ऐप मूल रूप से एक सम्मेलन का साथी है। मैं पैन और ज़ूम करने की क्षमता वाले होटल के नक्शों को शामिल करना चाहता हूं। आकार और प्रदर्शन कारणों से उच्च-रिज़ॉल्यूशन रेखापुंज का उपयोग करना अव्यावहारिक है; वेक्टर ग्राफिक्स एकदम सही हैं।

अभी मैं एक एम्बेडेड पीडीएफ वेबव्यू का उपयोग कर रहा हूं, जो बहुत असुविधाजनक है और केवल ऑनलाइन काम करता है (हालांकि अगर मुझे करना होता तो मैं शायद इसके आसपास काम कर सकता था)।

• कस्टम 'लुक-अलाइक रियल' नॉब्स वेक्टर ग्राफिक्स के बिना व्यावहारिक रूप से अप्राप्य हैं। विशेष रूप से वे जो कतरनी को घुमाते, तिरछा या पिघलाते हैं।

डैन ने जो कहा है उसे जोड़ने के लिए: केवल 1kB वेक्टर स्रोत 7 "टैबलेट और 105" 4HD टीवी दोनों पर बढ़िया विवरण, चिकनी तस्वीर का उत्पादन कर सकता है। 10 या 14" (कैशियर फेसिंग) और 5 या 7" (कस्टमर फेसिंग) स्क्रीन के लिए कैश रजिस्टर कियोस्क ऐप से हालिया मामला। उपहारों के सभी 5000+ वेक्टर ड्रॉइंग के सेट का आकार 5MB से कम था। सिर्फ 'सब्जियों' के उपसमुच्चय (~ 150) को पीएनजी में परिवर्तित किया गया था, ठीक दो स्क्रीन के लिए इस्तेमाल किया गया था जो 30 एमबी से अधिक था। पूर्ण इन्वेंट्री सेट GBytes श्रेणी में समाप्त हो सकता है।

पीएस अगली बड़ी बात यह होगी कि वेक्टर ग्राफिक्स को स्पर्श क्षेत्रों के साथ परिभाषित किया जाए, उदाहरण के लिए, एक चुने हुए भरण के माध्यम से। यह ज्यादातर स्थिर लेकिन विस्तृत समृद्ध इंटरफेस के पूरे वर्ग के लिए कोड की हजारों लाइनों को बख्श देता।
जैसा कि इंटरैक्टिव मशीनरी ऑपरेटर के मैनुअल में है।

सपने एक तरफ - बस हमारे डिजाइनरों को पहले सरल वेक्टर चित्र का उपयोग करने दें :)

अब तक की प्रतिक्रिया के लिए धन्यवाद। बहुत मददगार।

@ohir क्या आप "घुमाने, तिरछा या पिघलाने" के बारे में विस्तार से बता सकते हैं?

इसके लिए मेरा समाधान है कि मैं वास्तव में बहुत खुश हूं path_parsing पैकेज का उपयोग करना (https://pub.dev/packages/path_parsing) एक एसवीजी पथ स्ट्रिंग से कैनवास ड्राइंग कमांड उत्पन्न करने के लिए और फिर उनका उपयोग करना एक CustomPainter विजेट बनाने के लिए जो इसे खींचता है। पथ (रेक्ट, सर्कल, आदि) के अलावा अन्य एसवीजी आकृतियों के लिए मैं उन्हें मैन्युअल रूप से ड्राइंग कमांड में अनुवाद करता हूं जो थोड़ा कठिन है लेकिन बहुत कठिन नहीं है।

यह सरल वेक्टर आइकन के लिए वास्तव में अच्छी तरह से काम करता है और आपको पूरे ऐप में विभिन्न आकारों और रंगों के साथ एक ही विजेट का उपयोग करने की अनुमति देता है।

यहाँ कोड है: https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908

यह वास्तव में उपयोगी हो सकता है यदि कोई आधिकारिक स्पंदन कमांड लाइन उपकरण था जो एक एसवीजी फ़ाइल को पार्स करता था और कैनवास ड्राइंग कमांड का उत्पादन करता था जो एक समान परिणाम उत्पन्न करता था।

@ हिक्सी
उदा. https://dribbble.com/shots/1083175-Air-conditioning-controller#
सेंट्रल रोटेटिंग नॉब और उसके चारों ओर का गेज वर्तमान कैनवास एपीआई के साथ सावधानीपूर्वक खींचा जा सकता है, लेकिन यह 2Kb (xml svg) में भी फिट हो सकता है, फिर लगभग 300-500B ड्रॉएबल। कुछ 'वेक्टर ग्राफिक्स' इंटरफेस के माध्यम से उजागर किए गए स्की स्तर से वेक्टर ग्राफिक्स और अल्पविकसित एफ़िन परिवर्तन थे, इस घुंडी को केवल गेज सेगमेंट में भरने और संकेतक छोटे सर्कल के पथ को घुमाने के साथ जीवंत बनाया जा सकता था।

अधिक महत्वपूर्ण यह है कि रंगों और अन्य विवरणों के साथ यह पूरी घुंडी बिल्कुल डिज़ाइनर की योजना के अनुसार तैयार की जाएगी - क्योंकि यह उसका सारा काम सिर्फ एम्बेडेड होगा। वेक्टर ड्रॉइंग का इंटरफ़ेस + फिल + ग्रेडिएंट्स + अच्छा डिज़ाइनर ऐसा दिखाई दे सकता है: https://www.artua.com/app-design-decadance/
डेवलपर की ओर से एफ़िन ट्रांसफ़ॉर्मेशन इस तरह के डिज़ाइन को उत्तरदायी और जीवंत बना देगा।
तिरछा, और कतरनी परिवर्तनों के लिए: उदाहरण के लिए। एक नियंत्रण लीवर बदलाव को मॉडल करने के लिए इस्तेमाल किया जा सकता है।
("पिघल" शब्द-शिफ्ट की संभावना सल्वाडोर डाली के भूत से प्रेरित है;)

/विषय से परे/

@jpotterm
यह वास्तव में उपयोगी हो सकता है यदि कोई आधिकारिक स्पंदन कमांड लाइन उपकरण था जो एक एसवीजी फ़ाइल को पार्स करता था और कैनवास ड्राइंग कमांड का उत्पादन करता था जो एक समान परिणाम उत्पन्न करता था।

मैंने कुछ ऐसा ही प्रोड्यूस किया है। कोड जनरेटर जो एक एनोटेशन की तलाश करता है और, निर्दिष्ट एसवीजी पाथडाटा लेता है और एक गेटर उत्पन्न करता है जो पथ ऑब्जेक्ट देता है। अगर लोग चाहें तो मैं इसे साफ कर सकता हूं और इसे खोल सकता हूं।

मैं जिस ऐप में योगदान देता हूं वह वेक्टर ग्राफिक्स के लिए पूरी तरह से अनुकूल है। इसमें सैकड़ों छोटे ब्लैक एंड व्हाइट लाइन आर्ट ग्राफिक्स हैं जो UI का निर्माण करते हैं। इन्हें रंगा और आकार बदला जा सकता है।

सभी अलग-अलग घनत्वों पर कई रंगों में ऐसा करना भयानक, अस्थिर और अंतिम पैकेज को विशाल बनाना होगा। ये चित्र हाथ से खींचे गए ग्राफिक्स से आते हैं।

आपकी प्रतिक्रिया के लिए सभी को धन्यवाद। बहुत उपयोगी टिप्पणियाँ।

उन लोगों के लिए जो वेक्टर ग्राफिक्स प्रारूप में दिलचस्प हैं, मैं आपके उपयोग के मामलों के बारे में उत्सुक हूं।

एक अन्य उपयोग का मामला मूल रूप से कुछ भी है जिसे गतिशील ग्राफिक्स की आवश्यकता होती है:

• चार्ट
• लोडिंग बार
• चित्रकारी
• आदि

मैं वास्तव में बहुत हैरान हूं कि स्पंदन इसका समर्थन नहीं करता है क्योंकि स्की को एसवीजी (वैसे भी उपयोगी भागों) के सबसेट के लिए समर्थन है।

मैं कला के लिए एसवीजी का उपयोग करना चाहूंगा। एक गुणवत्ता पूर्ण स्क्रीन टैबलेट पीएनजी 2 एमबी या अधिक हो सकता है, जबकि इसके समकक्ष एसवीजी 5-10kb हो सकता है। कुछ स्क्रीन जोड़ें, और हम 100kb के बजाय पैकेज में 20mb की बात कर रहे हैं।

प्रोग्रामेटिक ग्राफिक्स के लिए मैं कस्टमपेंट का बहुत बड़ा प्रशंसक हूं इसलिए मैं चार्ट, लोडिंग बार, ड्राइंग इत्यादि जैसी चीजों के लिए कभी भी एसवीजी का उपयोग नहीं करता। कस्टमपेंट एपीआई के बारे में चिंतित लोगों के लिए, यह मानसिक रूप से एचटीएमएल कैनवास एपीआई की तरह है। और हां, जबकि मैं मानता हूं कि CustomPaint में सामान लिखना महंगा है, अंत में आपको जो मिलता है वह रॉक सॉलिड है और बहुत तेज और बहुत खूबसूरती से प्रस्तुत करता है।

यदि आप एसवीजी का समर्थन करने जा रहे हैं, तो आपको सभी एसवीजी सुविधाओं का समर्थन करना होगा, जैसे ग्रेडिएंट, स्ट्रोक और बहुत कुछ। यह एंड्रॉइड प्रोजेक्ट में नहीं किया गया था और यह डेवलपर्स के लिए कुछ चेतावनियां ध्वज उठाता है, क्योंकि लगभग सभी अन्य देव। प्लेटफॉर्म एसवीजी और वैक्टर का समर्थन करते हैं। यह ग्राफ़िक्स की मूल बातें हैं, इसे ठीक से करें!

@harounhajem कृपया उस विषय के लिए https://github.com/flutter/flutter/issues/15501 और साथ ही https://github.com/dnfield/flutter_svg देखें ।

@PierBover चार्ट के लिए विशेष रूप से कृपया https://pub.dev/packages/charts_flutter . पर विचार करें

मैं अभी स्पंदन में कूद गया। मैं आयोनिक 3 से आयोनिक 4 में एक व्यक्तिगत ऐप को फिर से सक्रिय कर रहा था और यह (फिर से) पूरी तरह से अलग था और इसे स्क्रैच से एक ऐप की आवश्यकता थी।
इसलिए मैंने फ़्लटर में जाने और इसे आज़माने का फैसला किया। जैसा कि मैंने कहा, मेरे पास यह ऐप समाप्त हो गया था और काम कर रहा था और इसमें बहुत सारे ग्राफिक्स और आइकन शामिल हैं जो मैंने अपने ऐप पर तैयार किए थे। मैं एक डिजाइनर नहीं हूं और मुझे इस डिजाइन के लिए भुगतान करना होगा।
मैं समझता हूं कि इस स्थिति में मैं अकेला नहीं हूं, अपनी एसवीजी संपत्तियों का पुन: उपयोग करना चाहता हूं।

@erperejildo - देखें https://pub.dev/packages/flutter_svg

(सुनिश्चित नहीं है कि यह बंद क्यों नहीं है)

क्योंकि वास्तविक समस्या—SVG के अलावा किसी वेक्टर ड्रॉएबल प्रारूप का समर्थन—समाधान नहीं है?

ओह, मेरी गलती @jonahgreenthal। मैं यहां एसवीजी समर्थन की तलाश में आया था और देखा कि तीसरी टिप्पणी उसी चीज के लिए पूछ रही थी

उबेर ने आईओएस के लिए ऐसा किया है: https://github.com/uber/cyborg
स्पंदन में ऐसा कुछ देखना दिलचस्प होगा।

इस पर कोई अपडेट?

@dnfield जिसने एक svg को नए विजेट के रूप में प्रदर्शित करने के लिए ठीक काम किया लेकिन यह AssetImage संपत्ति के साथ काम नहीं करता है। मुझे इसे CircleAvatar विजेट का उपयोग करके प्रदर्शित करने की आवश्यकता है

@ हिक्सी एक उपयोग का मामला भी है जहां svg आइकन के लिए कई रंग होने चाहिए क्योंकि यह उपयोगकर्ता को आइकन के अर्थ को समझने में मदद करता है। इसलिए मुझे उम्मीद है कि समाधान में थीम रंग को भी अनुकूलित करने की क्षमता शामिल होगी।

वर्तमान में, कुछ लोग एसवीजी को फॉन्ट में बदलने का सुझाव देते हैं और इसका उपयोग उसी तरह करते हैं जैसे कि आइकन पैकेज ने किया था, हालांकि इस मामले में हमारे पास आइकन में एक से अधिक रंग नहीं हो सकते हैं।

बिना किसी उपयोगी समाधान के 4 साल की विभिन्न टिप्पणियाँ। संक्षेप में - नहीं, संभव नहीं। नहीं, नियोजित नहीं।

क्या हम कम से कम यह जान सकते हैं कि यह इतना समस्याग्रस्त/कठिन क्यों है?

Flutter_svg को स्पंदन में SVG के लिए अच्छा समर्थन प्राप्त है। रिव स्पंदन के लिए एक वेक्टर आधारित प्रारूप का भी समर्थन करता है।

यह मुद्दा एक नया वेक्टर आधारित प्रारूप बनाने के बारे में है। इसमें समय लगता है :)

@dnfield पृष्ठभूमि गुणों के साथ कुछ विजेट हैं जिन्हें हम svgs पास नहीं कर सकते हैं। क्या इसे संग्रहित करने का कोई तरीका है?

कृपया एक नया प्रारूप बनाने के बजाय उचित svg समर्थन जोड़ें। Svg वास्तविक मानक है।

जब भी मैं कोई ऐप बनाता हूं, आमतौर पर एक संबद्ध वेबसाइट होती है, और वेबसाइटें svg का उपयोग करती हैं, और वे खूबसूरती से एनिमेटेड svgs का उपयोग करती हैं, जो किसी भी रिज़ॉल्यूशन पर हल्के और सुंदर होते हैं।
फ़्लटर में उन एनिमेटेड svgs का पुन: उपयोग करना वास्तव में समझ में आता है ताकि छवियों और एनिमेशन को फिर से लागू करने के बजाय स्थिरता को ठीक से प्राप्त किया जा सके!

एसवीजी पहले से मौजूद है, काम करता है, और व्यापक रूप से उपलब्ध है और हर जगह इस्तेमाल और समर्थित है। हमें जिस चीज की जरूरत है, उस पर फोकस करें।

यह मुद्दा एक नया वेक्टर आधारित प्रारूप बनाने के बारे में है

तो आपका मतलब है, यह मुद्दा पहिया को फिर से शुरू करने के बारे में है, है ना? मैं @ d-silveira से सहमत हूं - बेहतर ऐड बिल्ट इन, svg के लिए उचित समर्थन, हमें किसी नए वेक्टर आधारित प्रारूप की आवश्यकता नहीं है।

हाँ, यह एक बेहतर पहिये का आविष्कार करने के बारे में है। SVG पहले से ही Flutter_svg का उपयोग करके Flutter में समर्थित है।

एसवीजी आयात करने और उन्हें आंतरिक रूप से संसाधित करने में सक्षम होने के लिए बेहतर है, या तो निर्माण समय पर या आयात के दौरान ऑटो जनरेट कोड। देशी एंड्रॉइड के समान - आप एसवीजी आयात कर सकते हैं और एंड्रॉइड पथ परिभाषा एक्सएमएल स्रोत एसवीजी से उत्पन्न होगी। स्पंदन परियोजना में आयात डार्ट कोड उत्पन्न कर सकता है जिसे वेक्टर संपत्ति को आकर्षित करने के लिए पुन: उपयोग किया जा सकता है।

@Hixie चीजों को बेहतर बनाने के लिए अच्छा है, मैं उस पर चर्चा नहीं करूंगा, लेकिन हम कुछ विजेट्स का समर्थन कैसे कर सकते हैं जो इस दौरान केवल गैर svg छवियों की अनुमति देते हैं? (उदाहरण के लिए पृष्ठभूमि गुणों वाले)

यह flutter_svg के लिए एक सुविधा अनुरोध होगा।

@ हिक्सी स्पंदन एसवीजी वहां एक छवि बना सकता है, लेकिन यह अच्छा होगा यदि ढांचा कुछ मामलों में छवियों के बजाय चित्र लेने के लिए अधिक सहिष्णु था। फाइल किया गया https://github.com/flutter/flutter/issues/49712

स्पंदन_एसवीजी

ऐसा क्यों है? यह flutter_svg पैकेज से बिल्कुल भी संबंधित नहीं है:

CircleAvatar(
  backgroundImage: MySVGImage(),
)

@Hixie flutter_svg केवल कुछ मामलों के लिए ही काम करेगा। मैं आपको एक व्यावहारिक उदाहरण देता हूं: मुझे एक आरईएसटी एपीआई का उपभोग करने की ज़रूरत है जो इसके कुछ समापन बिंदुओं में छवियों के यूआरएल देता है। छवियां बैकऑफ़िस में उत्पन्न उपयोगकर्ता हैं, इसलिए उनमें से कुछ पीएनजी हैं, कुछ जेपीजी हैं और कुछ एसवीजी हैं। बैकऑफ़िस में url में फ़ाइल एक्सटेंशन शामिल नहीं है, और HEAD का समर्थन नहीं करता है, इसलिए हमारे पास समय से पहले छवि प्रकार को जानने का कोई तरीका नहीं है।
स्पंदन का अपेक्षित व्यवहार image.network में url प्राप्त करना और इसे संभालना होगा, बजाय मुझे हुप्स के माध्यम से कूदने के लिए यह अनुमान लगाने के लिए कि यह किस प्रकार की छवि है, और यदि यह svg है, तो Flutter_svg पर स्विच करें।
यह सब इस तथ्य को भी ध्यान में नहीं रखता है कि फ़्लटर_एसवीजी हर मामले में छवि के लिए ड्रॉप-इन प्रतिस्थापन नहीं है! :पी

सामान्य तौर पर एसवीजी केवल कुछ उपयोग के मामलों के लिए भी काम करेगा। :-)

यह विशिष्ट समस्या एक गैर-एसवीजी वेक्टर ग्राफिक्स प्रारूप होने के बारे में है। यदि आपकी कोई अलग आवश्यकता है, तो मैं इसे एक अलग मुद्दे के रूप में दाखिल करने की अनुशंसा करता हूं।

पहले की चर्चा से, कुछ महत्वपूर्ण विचार इस प्रकार हैं:

• हम पूर्ण SVG समर्थन नहीं चाहते हैं। कल्पना में बहुत अधिक है जो महंगा है, भारी है, और/या स्पंदन में हमारे पास पहले से ही डुप्लिकेट है।
• हमें अपने समर्थित प्रारूप में इस बात पर जोर देना चाहिए कि वे ऑपरेशन हमारे ग्राफिक्स इंजन (स्किया) में प्रभावी/कुशल/अनुकूलित हैं।
• हम एक पूर्ण रन-टाइम दुभाषिया का समर्थन करने के बजाय बिल्ड समय पर प्रारूप को संसाधित करना चाह सकते हैं।

तो कोई स्पंदन के लिए अनुकूलित छवियों के लिए एक नया वेक्टर प्रारूप बनाने के बारे में कैसे जाता है? ऊपर के आधार पर मुझे लगता है कि यही सुझाव दिया जा रहा है ...

हो सकता है कि Rive के लोग कुछ SVG कनवर्टिंग लाइब्रेरी को एक साथ रख सकें। उनके पास पहले से ही Flutter के लिए एक मालिकाना (और खुला स्रोत) वेक्टर इंजन है। @ लुइगी-रोसो

स्पंदन परियोजना में svg आयात करने के लिए समर्थन क्यों नहीं जोड़ा जाए। और डार्ट कोड/नए वेक्टर ड्रॉएबल आदि में कनवर्ट करें। ध्यान दें कि वही स्थिति देशी एंड्रॉइड पर है, इसलिए हम सीधे एसवीजी का उपयोग नहीं करते हैं (जो मैं मानता हूं कि इसका कोई मतलब नहीं है) और इसके बजाय प्रोजेक्ट में आयात करें, एसवीजी से छीन लिया गया है समर्थित नहीं है और कार्यात्मकता की आवश्यकता नहीं है और एंड्रॉइड पथ परिभाषा में परिवर्तित हो गया है।

क्या स्पंदन के लिए यह अच्छा विचार नहीं है?

@ giaur500 यह मुद्दा उसके बारे में नहीं है। यदि आपके पास विशेष रूप से एसवीजी के बारे में कोई सुझाव है, तो कृपया एक अलग मुद्दा दर्ज करें।

निष्पक्ष होने के लिए, इस मुद्दे में कई टिप्पणियां एसवीजी और स्पंदन पर चर्चा कर रही हैं।

अनुसरण करना

एसवीजी महान पिक्सेल-स्तरीय यूजर इंटरफेस के लिए एकदम सही है। महान पिक्सेल के लिए अब तक का सबसे अच्छा।

@lukepighetti हाँ। दुर्भाग्य से वे सभी विषय से हटकर हैं और उनके यहां होने से स्पंदन में कोई सुधार नहीं होगा।

पहले की चर्चा से, कुछ महत्वपूर्ण विचार इस प्रकार हैं:

• हम पूर्ण SVG समर्थन नहीं चाहते हैं। कल्पना में बहुत अधिक है जो महंगा है, भारी है, और/या स्पंदन में हमारे पास पहले से ही डुप्लिकेट है।
• हमें अपने समर्थित प्रारूप में इस बात पर जोर देना चाहिए कि वे ऑपरेशन हमारे ग्राफिक्स इंजन (स्किया) में प्रभावी/कुशल/अनुकूलित हैं।
• हम एक पूर्ण रन-टाइम दुभाषिया का समर्थन करने के बजाय बिल्ड समय पर प्रारूप को संसाधित करना चाह सकते हैं।

एक बिल्ड टाइम टूल बहुत अच्छा होगा, वेक्टर लें और सभी स्क्रीन घनत्वों को प्रस्तुत करें, और संपत्तियों को छवियों के रूप में जोड़ें। Apple iOS ऐसा PDF आइकॉन के साथ करता है।

एसवीजी आयात करने और उन्हें आंतरिक रूप से संसाधित करने में सक्षम होने के लिए बेहतर है, या तो निर्माण समय पर या आयात के दौरान ऑटो जनरेट कोड। देशी एंड्रॉइड के समान - आप एसवीजी आयात कर सकते हैं और एंड्रॉइड पथ परिभाषा एक्सएमएल स्रोत एसवीजी से उत्पन्न होगी। स्पंदन परियोजना में आयात डार्ट कोड उत्पन्न कर सकता है जिसे वेक्टर संपत्ति को आकर्षित करने के लिए पुन: उपयोग किया जा सकता है।

मुझे यह पसंद है

@ giaur500 यह मुद्दा उसके बारे में नहीं है। यदि आपके पास विशेष रूप से एसवीजी के बारे में कोई सुझाव है, तो कृपया एक अलग मुद्दा दर्ज करें।

नया मुद्दा बनाया गया है: https://github.com/flutter/flutter/issues/63752

तो इसकी क्या स्थिति है?
क्या एंड्रॉइड पर उन लोगों के लिए वेक्टर ड्रावेबल, या यहां तक ​​​​कि वेक्टर ड्रावेबल के समान कुछ का समर्थन करने का कोई इरादा है?

एक डेवलपर के रूप में पारिस्थितिकी तंत्र को अपनाने पर विचार कर रहा हूं, मैं कहूंगा कि यह एक मजबूत बिंदु है जो मुझे देशी रहने के लिए मनाएगा ..

मैंने इसे स्वयं कभी नहीं आजमाया, लेकिन स्पंदन svg lib को at . के लिए समर्थन मिला करता था
पथों की तरह आकर्षित करने योग्य वेक्टर की कम से कम प्रमुख विशेषताएं।

शनिवार, 15 अगस्त 2020, 19:46 n00bmind पर, [email protected] ने लिखा:

तो इसकी क्या स्थिति है?
क्या कुछ इसी तरह का समर्थन करने का कोई इरादा है
वेक्टर ड्रायबल, या यहां तक ​​​​कि वेक्टर ड्रायबल भी एंड्रॉइड पर उन लोगों के लिए?

एक डेवलपर के रूप में पारिस्थितिकी तंत्र को अपनाने पर विचार करते हुए, मैं कहूंगा कि यह एक है
मजबूत बिंदु जो मुझे देशी रहने के लिए मनाएगा ..

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

मुझे लगता है कि राज्य कुछ भी नहीं है। इस धागे से यहां कोई निष्कर्ष मौजूद नहीं है और मेरा विचार देशी वेक्टर ड्रॉएबल के समान कुछ विकसित करने के लिए तुरंत बंद हो गया है।

क्या कोई कारण है कि स्पंदन svg पैकेज आपके लिए काम नहीं करेगा? हम इसे अपने एक ऐप में बड़ी सफलता के साथ उपयोग कर रहे हैं। मैंने कभी भी वेक्टर ड्रायबल का उपयोग नहीं किया है, इसलिए मुझे यकीन नहीं है कि यह एसवीजी से कैसे तुलना करता है।

ऐसा लगता है कि इस तरह के उपयोग के मामले में flutter_svg पैकेज देखने लायक है।
@lukepighetti आप इसके प्रदर्शन को कैसे आंकेंगे? मेरा उपयोग सिर्फ एक स्पलैश छवि और ऐप में कुछ आइकन-आकार के ग्राफिक्स होंगे, इसलिए कुछ भी फैंसी नहीं है।

ऐसा लगता है कि इस तरह के उपयोग के मामले में flutter_svg पैकेज देखने लायक है।

@lukepighetti आप इसके प्रदर्शन को कैसे आंकेंगे? मेरा उपयोग सिर्फ एक स्पलैश छवि और ऐप में कुछ आइकन-आकार के ग्राफिक्स होंगे, इसलिए कुछ भी फैंसी नहीं है।

मैं आपके उपयोग के मामले के लिए इसे बहुत अधिक रेट करूंगा। मुझे लगता है कि स्पंदन टीम पर आंतरिक रूप से कुछ करने के लिए दबाव डालने से पहले लोगों को वास्तव में इसे आज़माना चाहिए।

@lukepighetti

इससे पहले कि वे स्पंदन टीम पर आंतरिक रूप से कुछ करने का दबाव डालें।

इस विशेष समस्या के साथ वास्तविक समस्या यह है कि स्कीया स्पंदन ग्राफिक्स इंजन में "ड्राइंग-लाइक" वेक्टर प्रारूप बनाने के लिए आवश्यक सब कुछ है जो बिना भारी डार्ट पैकेज को आयात किए बिना उच्चतम गति से चल रहा है जो इंजन को प्राइमेटिव्स को चरणबद्ध तरीके से आकर्षित करने के लिए कहता है।

मुझे लगता है कि लोगों को वास्तव में इसे _(svg package)_ एक कोशिश देना चाहिए

मुझे लगता है कि लोगों को ज़ोर से और हर संभव जगह पर इस gh-मुद्दे पर गोगलर्स को कॉल करना चाहिए, क्योंकि अब - चार साल बाद - केवल नकारात्मक पीआर किसी के बारे में सोचने के लिए Google पर लात मार सकता है कि क्या वर्ष 2020 में मोबाइल फ्रेमवर्क वास्तव में हमें ले जाने के लिए मजबूर कर रहा है। हमारे ऐप्स के भीतर वह सभी मेगाबाइट रैस्टर ग्राफ़िक्स।

[@ हिक्सी]

जब तक मुझे कुछ याद नहीं आ रहा है, इस तरह की स्पंदन सुविधा के लिए कार्यान्वयन @dnfield के flutter_svg पैकेज जैसा दिखता है जो आपके द्वारा वर्णित उपयोग के मामले को हल करने के लिए प्रतीत होता है। उसके ऊपर, मेंटेनर कोर फ़्लटर टीम में है, इसलिए हम इसकी गुणवत्ता के बारे में सुनिश्चित हो सकते हैं। यदि यह पैकेज https://github.com/flutter/plugins में होता तो क्या आप बेहतर महसूस करते?

अगर मुझे कुछ याद आ रहा है तो कृपया मुझे शिक्षित करने में संकोच न करें ताकि मैं इस विषय के बारे में और जान सकूं।

@lukepighetti

मुझे लगता है कि अंक के शीर्षक में "एसवीजी नहीं" को लाल, बोल्ड और चमकदार बनाया जाना चाहिए।

यह समस्या विशेष रूप से svg प्रारूप के बारे में नहीं है।

ओपी (और मुझे) को स्कीया के पथ एपीआई को उजागर करने की उम्मीद थी ताकि संपत्ति ग्राफिक्स को एक कॉम्पैक्ट रूप में प्रदर्शित किया जा सके - यानी निश्चित अंतहीनता का बाइनरी। डैन ने स्कीया के लिए एक पैच भी किया जो कि flutter_svg के लिए काम करता है, जो बदले में अब हमें svg संपत्ति का उपयोग करने की अनुमति देता है। हालांकि अभी भी हम ऐप रन टाइम पर एक्सएमएल को पार्स करते हैं और इंजन को कॉल करके ड्रा करते हैं - एपीके में बंडल की गई स्थिर संपत्तियों के लिए भी।

कस्टम वेक्टर ड्रॉएबल फॉर्मेट (इसे fvd नाम दें) के लिए उचित समर्थन के साथ, डिज़ाइनर कार्य का विश्लेषण एक बार होगा - ऐप बिल्ड समय पर, फिर fvd प्रारूप में ऑब्जेक्ट सीधे स्की पर फेंक दिया जाएगा। ग्राफिक्स-भारी ऐप में इस तरह के दृष्टिकोण से ऐप के आकार पर बहुत अधिक प्रभाव पड़ेगा और रेंडरिंग समय पर ध्यान देने योग्य बचत होगी। [ स्वयं का हवाला देते हुए ]

मुझे उम्मीद है कि ऊपर से पता चलता है कि मैं इस मुद्दे को कैसे देखता हूं और इसे अंतिम रूप देने के लिए अपने कॉल को सही ठहराता हूं।
Flutter_svg पुस्तकालय के एक भाग के रूप में भी।

स्पंदन प्रतिस्पर्धी प्रौद्योगिकियों पर एक और लाभ पाने का हकदार है।

इसके लायक क्या है, Flutter_svg का उपयोग करने में स्वाभाविक रूप से कुछ भी गलत नहीं है, यह सिर्फ इतना है कि इसमें कुछ बहुत ही सरल चीजों की कमी है, उदाहरण के लिए यह प्रतिशत का समर्थन नहीं करता है और उन्हें प्रस्तुत करने का प्रयास करते समय सीधे क्रैश हो जाता है। यह टिप्पणी flutter_svg पुस्तकालय पर दस्तक नहीं है, यह सिर्फ उन लोगों को समझाने के लिए है जो कह रहे हैं कि हम केवल flutter_svg का उपयोग कर सकते हैं।

फ़्लटर_एसवीजी स्क्रिप्टिंग, एचटीएमएल, एसएमआईएल इत्यादि का समर्थन न करने के बावजूद बहुत अच्छा काम करता है।

यह अच्छा लग रहा है और हम फाइल संपत्तियों, नेटवर्क या सामान्य तारों से एसवीजी बना सकते हैं।