2011-01-07 13 views
17

मैं जावा की हार्डवेयर त्वरण विशेषताओं को देखने में कुछ समय व्यतीत कर रहा हूं, और मैं अभी भी थोड़ा उलझन में हूं क्योंकि मुझे ऑनलाइन मिली कोई भी साइट सीधे और स्पष्ट रूप से मेरे कुछ प्रश्नों का उत्तर नहीं देती है। तो यहां जावा में हार्डवेयर त्वरण के लिए मेरे प्रश्न हैं:जावा हार्डवेयर त्वरण

1) मैक ओएस एक्स (1.6u10 मुझे लगता है) के लिए हालिया जावा अपडेट के साथ ग्रहण संस्करण 3.6.0 में, डिफ़ॉल्ट रूप से हार्डवेयर त्वरण सक्षम है? मैंने कहीं पढ़ा है कि

someCanvas.getGraphicsConfiguration().getBufferCapabilities().isPageFlipping() 

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

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

3) वहाँ

someGraphicsConfiguration.getCompatibleImage/getCompatibleVolatileImage() 

का उपयोग कर के रूप में

ImageIO.read() 

करने का विरोध एक ट्यूटोरियल मैं सही प्रकार से प्रस्तुत खिड़की की स्थापना के बारे में कुछ सामान्य अवधारणाओं के लिए पढ़ने की है में (tutorial के लिए किसी भी लाभ है) यह getCompatibleImage विधि का उपयोग करता है, जो मुझे लगता है कि एक बुफर्ड इमेज लौटाता है, ताकि तेजी से ड्राइंग के लिए "हार्डवेयर त्वरित" छवियां प्राप्त हो सकें, जो हार्डवेयर के त्वरित होने पर प्रश्न 2 में संबंध रखती है।

4) यह कम हार्डवेयर त्वरण है, लेकिन यह कुछ है जो मैं उत्सुक हूं: क्या मुझे ऑर्डर करने की आवश्यकता है कि कौन से ग्राफिक्स खींचे जाए? मुझे पता है कि सी/सी ++ के माध्यम से ओपनजीएल का उपयोग करते समय यह सुनिश्चित करना सबसे अच्छा होता है कि उसी ग्राफ़िक को उन सभी स्थानों पर खींचा जाता है जिन्हें इसे एक बार में खींचा जाना चाहिए ताकि वर्तमान बनावट को स्विच करने की आवश्यकता को कम किया जा सके। जो मैंने पढ़ा है, ऐसा लगता है जैसे जावा मेरे लिए इसका ख्याल रखेगा और सुनिश्चित करेगा कि चीजें सबसे इष्टतम फैशन में खींची जाएंगी, लेकिन फिर से, इस तरह कुछ भी स्पष्ट रूप से कुछ भी नहीं कहा है।

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

आपके समय के लिए बहुत बहुत धन्यवाद, और मुझे उम्मीद है कि मैंने आपके कई प्रश्नों के उत्तर देने के लिए स्पष्ट प्रश्न और पर्याप्त जानकारी प्रदान की है।

उत्तर

16

1) अब तक हार्डवेयर त्वरण डिफ़ॉल्ट रूप से कभी सक्षम नहीं होता है, और मेरे ज्ञान के लिए यह अभी तक नहीं बदला है। प्रतिपादन त्वरण को सक्रिय करने के लिए प्रोग्राम पर जावा लॉन्चर में इस तर्क (-Dsun.java2d.opengl = true) को पास करें, या किसी भी प्रतिपादन पुस्तकालयों का उपयोग करने से पहले इसे सेट करें। System.setProperty("sun.java2d.opengl", "true"); यह एक वैकल्पिक पैरामीटर है।

2) हाँ BufferedImage वाष्पशील स्मृति प्रबंध, क्योंकि जब BufferdImage त्वरित है इसकी एक प्रति एक VolatileImage के रूप में वि राम में संग्रहीत होता है विवरण में से कुछ समाहित।

एक BufferedImage को उल्टा रूप में लंबे समय है आप पिक्सल इसमें साथ खिलवाड़ नहीं कर रहे हैं के रूप में, बस उन्हें graphics.drawImage() जैसे एक कॉल को कॉपी, तो BufferedImage प्रतियां की एक निश्चित गैर निर्दिष्ट संख्या के बाद त्वरित किया जाएगा और यह प्रबंधन करेगा आपके लिए VolatileImage

एक BufferedImage के नकारात्मक पक्ष यह है अगर आप छवि संपादन कर रहे हैं, BufferedImage में पिक्सल बदल रहा है, यह इसके तेजी लाने के लिए कोशिश कर छोड़ देना होगा कुछ मामलों में, उस बिंदु पर आप देख रहे हैं कि यदि आपके संपादन के लिए performant प्रतिपादन के लिए है आप अपने VolatileImage के प्रबंधन पर विचार करने की आवश्यकता है। मुझे नहीं पता कि कौन से ऑपरेशन BufferedImage आपके लिए प्रतिपादन में तेजी लाने की कोशिश कर रहे हैं।

3) createCompatibleImage()/createCompatibleVolatileImage() का उपयोग करने का लाभ यह है कि ImageIO.read() एक डिफ़ॉल्ट समर्थित छवि डेटा मॉडल के लिए किसी भी रूपांतरण नहीं करता है। तो यदि आप एक पीएनजी आयात करते हैं तो यह पीएनजी रीडर द्वारा बनाए गए प्रारूप में इसका प्रतिनिधित्व करेगा। इसका मतलब यह है कि हर बार इसे GraphicsDevice द्वारा प्रस्तुत किया जाता है, इसे पहले एक संगत छवि डेटा मॉडल में परिवर्तित किया जाना चाहिए।

BufferedImage image = ImageIO.read (url); 
BufferedImage convertedImage = null; 
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); 
GraphicsDevice gd = ge.getDefaultScreenDevice(); 
GraphicsConfiguration gc = gd.getDefaultConfiguration(); 
convertedImage = gc.createCompatibleImage (image.getWidth(), 
              image.getHeight(), 
              image.getTransparency()); 
Graphics2D g2d = convertedImage.createGraphics(); 
g2d.drawImage (image, 0, 0, image.getWidth(), image.getHeight(), null); 
g2d.dispose() 

उपरोक्त प्रक्रिया एक छवि में परिवर्तित कर देंगे एक BufferedImage है कि एक छवि डेटा मॉडल डिफ़ॉल्ट स्क्रीन डिवाइस के साथ संगत करने के लिए एपीआई कब छवि के साथ में पढ़ा तो यह है कि रूपांतरण जगह लेने के लिए जब कभी यह प्रदान की गई है की जरूरत नहीं है । वह समय जब यह सबसे फायदेमंद होता है तब आप छवि को बहुत बार प्रस्तुत करेंगे।

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

5) मेरे सबसे अच्छे ज्ञान के लिए आपने जिस डिजाइन को रेखांकित किया है, वह है कि डबल बफरिंग मैन्युअल रूप से और सक्रिय रूप से एक एप्लिकेशन को प्रस्तुत करते समय बेहतर रणनीतियां में से एक है। http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html इस लिंक पर आपको BufferStrategy का विवरण मिलेगा।विवरण में यह एक कोड स्निपेट दिखाता है जो BufferStrategy ऑब्जेक्ट के साथ सक्रिय प्रतिपादन करने का अनुशंसित तरीका है। मैं अपने सक्रिय प्रतिपादन कोड के लिए इस विशेष तकनीक का उपयोग करता हूं। एकमात्र बड़ा अंतर यह है कि मेरे कोड में। आपके जैसे, मैंने Canvas के उदाहरण पर BufferStrategy बनाया है जिसे मैंने JFrame पर रखा है।

+0

क्या कोई विशेष कारण है कि अधिकांश/सभी उदाहरण कैनवास को स्टोर करने के लिए जेएफआरएएम का उपयोग करते हैं? जो मैंने समझा, उससे स्विंग बहुत भयानक है। आप फ़्रेम का उपयोग क्यों नहीं करेंगे? मेरे पास कोड है जो सिर्फ यही करता है, और ऐसा लगता है कि जेएफआरएएम से बनाना मुश्किल नहीं है। यह भी हार्डवेयर त्वरण सक्षम है अगर यह डिफ़ॉल्ट रूप से नहीं है? – Freezerburn

+0

@ फ्रीज़रबर्न मुझे नहीं पता कि अधिकांश उदाहरण जेफ्रेम बनाम फ़्रेम का उपयोग क्यों करते हैं। मुझे कल्पना है कि यह एक जेएफआरएएम के साथ किया जाता है क्योंकि यह सबसे अधिक ज्ञात है। यह केवल अटकलें है, लेकिन मुझे लगता है कि जावा में मैन्युअल रूप से केवल एक शीर्ष स्तर कंटेनर (जेएफआरएएम, फ़्रेम, इत्यादि) और कैनवास के साथ प्रतिपादन करना आपके द्वारा चुने गए बीच में थोड़ा अंतर है। प्रतिपादन त्वरण को सक्रिय करने के लिए इस तर्क (-Dsun.java2d.opengl = true) को प्रोग्राम लॉन्चर पर जावा लॉन्चर में पास करें, या किसी भी प्रतिपादन पुस्तकालयों का उपयोग करने से पहले इसे सेट करें। (System.setProperty ("sun.java2d.opengl", "true");) यह एक वैकल्पिक पैरामीटर है। – Zixradoom

+0

जेएफआरएएम स्विंग है जहां फ़्रेम/कैनवास एडब्ल्यूटी है। स्विंग नई घटक लाइब्रेरी है और एडब्ल्यूटी पुरानी बहिष्कृत लाइब्रेरी है। स्विंग हल्के वजन वाले घटकों का उपयोग करती है जहां एडब्ल्यूटी मूल घटक होता है। जेएफआरएएम पुराने एडब्ल्यूटी घटकों को पसंद करता है। – chubbsondubs

2

कुछ older documentation से निर्णय लेते हुए, आप सूर्य जेवीएम पर बता सकते हैं कि sun.java2d.opengl संपत्ति की जांच करके हार्डवेयर त्वरण चालू है या नहीं।

दुर्भाग्यवश, मुझे नहीं पता कि यह ऐप्पल जेवीएम पर लागू होता है या नहीं।

आप देख सकते हैं एक व्यक्ति की छवि हार्डवेयर है Image के getCapabilities(GraphicsConfiguration).isAccelerated()

यह सब कहा करने के बाद का उपयोग कर त्वरित, सभी प्रलेखन मैं (this one सहित) को देखा है मतलब कि BufferedImageनहीं हार्डवेयर त्वरित है। स्विंग को भी इस कारण से डबल-बफरिंग के लिए VolatileImage एस का उपयोग करने के लिए बदला गया है।

+0

मुझे sun.java2d.opengl संपत्ति कहां मिलेगी? मैंने इसे उल्लेख किया है, लेकिन मुझे कभी नहीं पता था कि इसे कहां देखना है या यह सुनिश्चित करने के लिए कि यह मैक/ग्रहण पर सक्षम था। इसके अलावा: http://download.oracle.com/javase/1.5.0/docs/guide/2d/new_features.html कहता है कि BufferedImages 1.5.0 में प्रबंधित किया जाता है और वीडियो मेमोरी में कैश किया जाता है। – Freezerburn

+0

चलो देखते हैं ... मुझे लगता है कि यह संपत्ति का मूल्य प्राप्त करने के लिए 'System.getProperty ("sun.java2d.opengl") है। 'बुफर्ड इमेज' के लिए, यह कहा गया है कि इसे वीडियो मेमोरी में कैश किया जा सकता है लेकिन वास्तव में इससे परे इसे छेड़छाड़ करने के बारे में कुछ नहीं कहता है। – Powerlord

+0

GetProperty के आउटपुट को प्रिंट करना मुझे कंसोल पर "शून्य" देता है। एक्सेलरेशन जावा में कैसे काम करता है, इसके बारे में मैं समझता हूं कि बुफर्ड इमेज वीडियो मेमोरी में होने वाली तेजी से प्रतिलिपि बनाने की इजाजत देता है कि वोल्टाइल इमेज का होना चाहिए? मुझे लगता है कि यह मामला होगा अगर यह वीडियो-टू-वीडियो प्रतिलिपि का उपयोग करता है। – Freezerburn

संबंधित मुद्दे