سرعة فك التشفير المذهلة لـ GDI+ وسرعة السحب الرهيبة!

Question

---

شكرًا على الإجابات، في الواقع أنا لست في حيرة بشأن رسم 1024*768 بكسل أبطأ من 100*100 بكسل...إنه منطق بسيط جداً..ما جعلني في حيرة من أمري هو أن خوارزمية الاستيفاء الخاصة بـ DrawImage قد تكون بطيئة جدًا، في حين أن هناك الكثير من الخوارزميات الأفضل، ويبدو أن وحدة فك التشفير الخاصة بها يمكنها فك التشفير من ملف jpg بدقة معينة، إنه أمر رائع حقًا، لقد بحثت عنه في وقت ما ولكن لم أجد أي شيء ليب مجاني للقيام بذلك ...

إنه أمر غريب حقا!أقوم بإضافة الكود التالي إلى طريقة الرسام.c:\1.jpg هو ملف jpg بحجم 5M، حوالي 4000*3000

//--------------------------------------------------------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,200,200);

ما سبق هو سريع حقا!حتى في الوقت الحقيقي!لا أعتقد أن فك تشفير ملف JPG بحجم 5 أمتار يمكن أن يكون بهذه السرعة!

//--------------------------------------------------------------

HDC hdc = pDC->GetSafeHdc();
bitmap = Bitmap::FromFile(L"c:\\1.jpg",true);
Graphics graphics(hdc);
graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
graphics.DrawImage(bitmap,0,0,2000,2000);

أصبح الكود أعلاه بطيئًا حقًا

//--------------------------------------------------------------

إذا أضفت Bitmap = Bitmap::FromFile(L"c:\1.jpg", true);// في البناء

يترك

    Graphics graphics(hdc);
    graphics.SetInterpolationMode( InterpolationModeNearestNeighbor );
    graphics.DrawImage(bitmap,0,0,2000,2000);

في طريقة onpaint ، لا يزال الرمز بطيئًا بعض الشيء ~~~

//------------------------------------------------------------------

بالمقارنة مع فك التشفير، فإن عملية drawImage بطيئة حقًا ...

لماذا وكيف فعلوا ذلك؟هل دفعت شركة مايكروسوفت للرجال المسؤولين عن وحدة فك التشفير راتبًا مضاعفًا مقارنة بالرجال المسؤولين عن كتابة رسم الصور؟

Answer 1

لا تحتاج إلى فك تشفير ملفات JPG إذا كنت تقوم بتقليص حجمها بمقدار 8.تتكون صور JPG من كتل بحجم 8 × 8 بكسل، محولة إلى DCT.متوسط ​​قيمة هذه الكتلة هو معامل DCT 0,0.لذا، فإن تقليل عامل 8 هو مجرد مسألة التخلص من جميع المكونات الأخرى.إن تقليص الحجم إلى أبعد من ذلك (على سبيل المثال 4000 -> 200) هو مجرد مسألة تقليص من 4000 إلى 500، ثم التحجيم بشكل طبيعي من 500 إلى 200 بكسل.

Answer 2

وهكذا، ما كنت أتساءل حقا هو السبب

graphics.DrawImage(bitmap,0,0,200,200);

وأسرع من

graphics.DrawImage(bitmap,0,0,2000,2000);

وتصحيح؟

وكذلك، فإن حقيقة أن كنت رسم 100 مرة أكثر بكسل في الحالة الثانية يمكن أن يكون شيئا لتفعله حيال ذلك.

Answer 3

ويمكن أن يكون من الممكن أن يتم تأجيل فك لحين الحاجة إليها. هذا هو السبب في أنه سريع جدا.

وربما على الصور 200x200 حالة GDI + يترجم فقط كتل كافية لرسم الصور 200x200 وعلى 2000x2000 أنها يترجم أكثر من ذلك.

والروتين الرسم يحتوي دائما بعض التحسينات غامضة، هل يمكن أن تعرف أبدا.

العاكس سوف اقول لكم؟

Answer 4

ومجرد تخمين، ولكن هل يمكن أن محاولة رسم مع 4000x3000 أو 2000x1500؟ ولعل حقيقة أن 4000 و 3000 هي القسمة على 200 تسرع كلها و 3000 عدم القسمة على 200 يبطئ عليه (على الرغم من أن هذا حقا سيكون غريب).

وعموما، والقيام ببعض التنميط أو قياس الوقت. إذا 2000x2000 حوالي 100 مرة أبطأ من الصور 200x200، كل شيء على ما يرام. ولا تهتم إذا 2000x2000 بطيئة جدا. إذا كانت الشاشة في 1024x768، لا يمكن أن نرى الصورة كاملة، لذلك يمكنك اختيار أفضل جزء من الصورة التي مرئيا على الشاشة واستدراجه، 1024x768 هو 5 مرات أسرع من 2000x2000.