المحاضرات والمنشورات

المناقشات والمحاضرات على هامش المؤتمرات

البرمجة الصحيحة مشكلة تواجه الجميع. دليل عملي وتفاعلي لتصحيح أخطاء التعليمات البرمجية للغة C++
سيباستيان ثيوفيل

نحب كتابة التعليمات البرمجية، لكن، على الرغم من بذلنا لقصارى جهدنا، فإننا نرتكب الأخطاء. وسوف يحتوي برنامجنا على أخطاء. في بعض الأحيان، لا نكتب ما ينبغي علينا كتابته، وأحيانًا لا نفهم جانبًا من جوانب لغة البرمجة، وفي أحيان أخرى نفتقر إلى، أو نفشل في وضع بعض المعلومات المهمة حول بيئة نظام برنامجنا في الاعتبار. ونتيجة لذلك، لن يعمل برنامجنا على نحوٍ صحيح. ماذا نفعل الآن؟ في هذه المحاضرة، أود أن أطلعكم على عملية تصحيح الأخطاء بأكملها، وسأبدأ بالبرنامج الذي يتعطل عن العمل. ماذا نفعل بعد ذلك؟ ما الأسئلة التي يجب أن نطرحها؟ ما المعلومات التي نحتاج إليها؟ ما الخطوات التي يمكننا القيام بها لإيجاد سبب العطل؟ ما الأدوات التي يمكن أن تساعدنا في هذا المسعى، وأخيرًا وليس آخرًا، ما الأمور التي يمكننا القيام بها لضمان عدم تكرار حدوث هذا الخطأ على الإطلاق؟ بفضل الأمثلة الواقعية التي واجهناها - وصححنا أخطاءها - في think-cell على مر السنين، ستتعلم كيفية تكرار أصعب الأخطاء وتحديد موقعها وفهمها وإصلاحها.

---

Typescripten — إنشاء روابط JavaScript من النوع الآمن لأداة emscripten
سيباستيان ثيوفيل

أصبحت WebAssembly منصة مستهدفة شائعة جدًا لمطوري C++. وبفضل أداة emscripten، أصبح نقل التطبيقات الأصلية إلى WebAssembly سهلاً - طالما أن التطبيق لا يستخدم سوى المتصفح كجهاز عرض وإدخال. ومع ذلك، فإن أداة emscripten لا توفر مجمِّعات من النوع الآمن لواجهات برمجة تطبيقات JavaScript القياسية مثل واجهة برمجة تطبيقات معالجة DOM، ناهيك عن أي واجهة برمجة تطبيقات JavaScript أخرى توفرها تطبيقات الويب الحالية. ويرتكز تصميم أداتنا مفتوحة المصدر "typescripten" على ثلاث تقنيات قوية لسد هذه الفجوة. فهي تستخدم ملفات تعريف واجهة TypeScript وواجهة برمجة تطبيقات المحول البرمجي لـ TypeScript لإنشاء مجمِّعات C++ من النوع الآمن بناءً على emscripten. تحتوي TypeScript بالفعل على ملفات تعريف واجهة لأكثر من 7000 مكتبة JavaScript، والتي يمكنك الآن استخدامها بأمان من C++. ونسعى جاهدين لتصميم مجمِّعات C++ بحيث تبدو التعليمات البرمجية للغة C++ التي تستخدمها مشابهة للتعليمات البرمجية لـ TypeScript أو JavaScript المكافئة. ولكن، غالبًا ما تصعب ترجمة الدلالات الخاصة لـ Javascript وTypescript القائمتين على النموذج الأولي إلى لغة قائمة على النوع مثل C++. سأناقش التحديات التي واجهناها والخيارات التي اتخذناها عند تصميمنا لإطار العمل هذا.

---

كلمة Windows, macOS and the Web: الدروس المستفادة من التطوير عبر أنظمة أساسية متعددة في think-cell
سيباستيان ثيوفيل

على مدار اثني عشر عامًا، ظلت think-cell شركة برمجيات تعمل بنظام التشغيل Windows فقط، وتراكمت في قاعدة التعليمات البرمجية الخاصة بنا، والتي تحتوي على 700 ألف سطر من التعليمات البرمجية تقريبًا، العديد من التبعيات غير المقصودة للنظام الأساسي. ومنذ ست سنوات، قررنا نقل تطبيقنا إلى نظام التشغيل Mac. فأثَّر هذا التغيير على كل جزء من عملية التطوير لدينا: تنظيم المشروع ونظام الإصدار والطريقة التي نبرمج بها باستخدام لغة البرمجة C++ اليوم. كانت المكتبات المشتركة بين الأنظمة الأساسية شائعة الاستخدام مثل Qt وBoost أدوات جيدة للإصدار عليها، ولكنها لم تكن في حد ذاتها كافية. بالنسبة للعديد من المفاهيم، مثل الاستبعادات المتبادلة أو الإعلامات الإشارية أو الذاكرة المشتركة، فإنها توفر فقط واجهة مشتركة للكائنات الخاصة بنظام أساسي ذات دلالات وأعمار مختلفة جدًا. ولهذا أردنا عمليات تجريد C++ خفيفة الوزن ومستقلة عن النظام الأساسي بدلالات متطابقة للعرض والتدويل ودخل/خرج الملفات ومعالجة أحداث الماوس واستدعاءات RPC والإبلاغ عن الأخطاء. ولقد كان تطوير هذه العناصر أمرًا صعبًا، أولاً، لأنه كان علينا تحديد الدلالات التي يحتاجها تطبيقنا، وثانيًا، لأننا اضطررنا إلى تنفيذها على كل نظام أساسي. ولم تكن هذه عملية سهلة ولكني أرى أنها أدت إلى تحسين جودة التعليمات البرمجية الخاص بنا كثيرًا. وانتقلنا الآن إلى التحدي التالي وبدأنا في نقل بعض الوظائف إلى تطبيقات الويب. فأردنا إعادة استخدام قاعدة التعليمات البرمجية الموجودة لدينا بالفعل، وهذا يعني كتابة تطبيقات الويب بلغة C++ معبرة ومن النوع الآمن. وهذه بالتأكيد ميزة في كتابنا! لقد قمنا ببناء تطبيقات الويب الخاصة بنا باستخدام أداة emscripten، ولكننا نقوم بإنشاء روابط C++ من النوع الآمن من أي تعريف لواجهة TypeScript. سأقدم لكم، في محاضرتي، نظرة عامة على عمليات تجريد ++C التي تطبقها think-cell، وسأركز على مواضع المشكلات عبر الأنظمة الأساسية حيث كان من الصعب تعريف الدلالات العامة بسبب قيود أي من نظامي التشغيل، وبالطبع، سأعرض لكم أدواتنا التي تتيح لنا كتابة تطبيق ويب بلغة ++C.

---

كارثة مدة بقاء C++ rvalue
أرنو شودل

ظلت مراجع Rvalue معنا منذ C++11. وقد تم ابتكارها في البداية لجعل الكائنات المتحركة أكثر كفاءة: ومن المفترض أن يخرج الكائن الذي يرجع إليه أي مرجع rvalue عن النطاق قريبًا وبالتالي قد تتم إزالة موارده دون ضرر. تستفيد مكتبة C++ القياسية، على سبيل المثال std::cref أو std::ranges، من جانب آخر من مراجع rvalue: نظرًا لأنها ستخرج عن النطاق قريبًا، فمن المفترض أنه من غير الآمن الاحتفاظ بها خارج نطاق الدالة الحالية، في حين تُعتبر مراجع lvalue آمنة. وقد وجدنا أيضًا أن هذا الافتراض مفيد جدًا لإدارة الذاكرة الذكية، خاصة في التعليمات البرمجية العامة.
ولسوء الحظ، فإن لغة C++ نفسها تنتهك هذا الافتراض. ترتبط Rvalues بـ const&. وهذا يعني أن الدوال ذات المظهر البريء تحول rvalues في صمت إلى مراجع lvalue، وهو ما يؤدي إلى إخفاء أي قيود على مدة بقاء rvalues. ويهدف التمديد المؤقت لمدة البقاء إلى جعل ارتباط المؤقت بأي مرجع آمنًا عن طريق تمديد مدة بقاء المؤقت. ولكن هذا لا ينجح إلا إذا كان المؤقت prvalue، وينفصل بالفعل عن rvalue، ناهيك عن قيم Ivalue المولدة بشكل صوري. ليست هذه المشكلات مجرد مشكلات نظرية فحسب. فقد واجهنا تلفًا في الذاكرة يصعب تحديده في التعليمات البرمجية الخاصة بنا بسبب هذه المشكلات. وفي هذه المحاضرة، سأصف المشكلات بالتفصيل، وأقدم منهجًا مستندًا إلى المكتبة فقط لتخفيف المشكلات، وأقدم عرضًا لاستحالة الوصول إلى المعايير حول كيفية تصحيح الأمور.

---

نطاقات أفضل للغة البرمجة C++
أرنو شودل

ظلت النطاقات موجودة لفترة في معيار لغة البرمجة C++، ثم شقت طريقها إلى قواعد التعليمات البرمجية الحديثة. وفي think-cell، عملنا على تطوير مكتبة النطاقات الخاصة بنا واستخدامها لمدة 20 عامًا، وقد تم إنشاؤها على رأس المعيار وهي متوافقة معه، ولكنها تتجاوزه في العديد من الجوانب. وغالبًا ما يتم تكديس مهايئات النطاقات، عامل تصفية في أعلى التحويل في أعلى، وما إلى ذلك. ولجعل مثل هذا التكديس فعالاً، فإن التكرارات ليست جيدة بما فيه الكفاية. فنحن نستخدم مفهومًا جديدًا أكثر كفاءة وهو في الوقت ذاته متوافق مع التكرارات حتى يتمكن مستخدمو المكتبة من الاستمرار في استخدام التكرارات كما فعلوا من قبل. والمكتبة القياسية صارمة جدًا فيما يتعلق بالتمييز بين الحاويات وطرق العرض، ومهايئات النطاقات هي طرق عرض يجب أن تحافظ على مرجع للبيانات التي مهايئتها. وبدلاً من ذلك، فإننا نسمح لمهايئات النطاقات بالاحتفاظ بالبيانات بنفسها لجعلها مستقلة بذاتها ومقيًّمة ببطء في نفس الوقت. لا يسمح نموذج التكرار القياسي إلا بالتكرار الخارجي. ومع ذلك، فإن تنفيذ التكرار الداخلي غالبًا ما يكون أسهل بكثير من تنفيذ التكرار الخارجي. وبالنسبة للعديد من التطبيقات، يكون التكرار الداخلي كافيًا تمامًا وأكثر كفاءة من التكرار الخارجي. ولهذا، نقوم بضم التكرار الداخلي إلى عائلة النطاقات، لدرجة أن مستخدم المكتبة قد لا يعرف أو قد لا يهتم بنوع التكرار المستخدم. وتقوم الخوارزميات القياسية بإرجاع التكرارات واستخدام مكرر النهاية للإشارة إلى بعض الحالات الأحادية. ويمكننا، من خلال تخصيص قيم الإرجاع، أن نجعل التعليمات البرمجية الخاصة بنا أكثر إيجازًا وتعبيرًا، وذلك، على سبيل المثال، عن طريق التخلص من عمليات التحقق النهائية المرهقة من المكرر. تجعل هذه الميزات مجتمعة النطاقات أداة مثالية لتنسيق النص. يمكننا استخدام هذه النطاقات لتمثيل القيم التي يتعين تنسيقها، وتحويلها من الناحية المفاهيمية إلى سلاسل مقيّمة بصورة بطيئة. ويمكن استخدام هذه السلاسل كما تُستخدم السلاسل المعتادة اليوم: في عمليات إرجاع الوظائف؛ وكإدخال خورازمية قياسي؛ وبصورة مضمنة في سلاسل أخرى مقيّمة بصورة بطيئة مكافئة؛ وهكذا، قبل توسيعها في النهاية للعرض. ويمكننا، عن طريق اختيار الواجهات الصحيحة، تحسين هذا التوسيع في وقت التحويل البرمجي، وهو ما يسمح ببناء جمل جيدة وأداء قريب جدًا من التعليمات البرمجية المحسّنة يدويًا.

---

Range-Based Text Formatting - For a Future Range-Based Standard Library (تنسيق النص المستند إلى النطاق - ليناسب مكتبة قياسية مستقبلية مستندة إلى النطاق)
أرنو شودل

لا يزال تنسيق النص مشكلة مفضلة لمؤلفي مكتبة ++C منذ فترة طويلة. في هذه الكلمة، أود اقناعكم بأن مزج النطاقات مع القليل من البرمجة الوصفية سيؤدي إلى الوصول إلى حل شديد الروعة لمشكلة تنسيق النص. نقدم شكلاً من النطاقات مع تكرار داخلي، والتي تعمل على إنشاء عناصر واحدًا تلو الآخر بدلاً من كشف المكررات الخارجية. يمكننا استخدام النطاقات المُنشئة هذه لتمثيل القيم التي يتعين تنسيقها، وتحويلها من الناحية المفاهيمية إلى سلاسل مقيّمة بصورة بطيئة. ويمكن استخدام هذه السلاسل كما تُستخدم السلاسل المعتادة اليوم: في عمليات إرجاع الوظائف؛ وكإدخال خورازمية قياسي؛ وبصورة مضمنة في سلاسل أخرى مقيّمة بصورة بطيئة مكافئة؛ وهكذا، قبل توسيعها في النهاية في حاوية. من خلال اختيار الواجهات الصحيحة، يمكننا تحسين هذه التوسعة بحيث تصبح أبطأ بنسبة 15% فقط من إنشاء السلسلة المكافأة باستخدام رمز محسّن يدويًا ذي حالة خاصة.

---

لماذا تُفهم المكررات كلها خطأ — وما الذي ينبغي استخدامه بدلاً منها
أرنو شودل

يمكنك فهم المكررات، أليس كذلك؟ كيف يمكنك شرحها؟ "تُستخدم المكررات للإشارة إلى سلسلة من العناصر." هل يبدو ذلك واضحًا؟ ولكن تم إدخال مفهوم المجالات مؤخرًا ليشير إلى أي شيء يعرض المكررات. وعلى وجه التحديد، تتضمن المجالات مهايئات المجالات لنقل تسلسلات العناصر أو تصفيتها ببطء، كما تحتوي أيضًا على مكررات.
هل كل شيء على ما يرام؟ للأسف، لا. لأن مفهوم المكرر الذي استخدمناه منذ ظهور لغة C++‎ معيب في جوهره. وبالتحديد، يجب أن تتصرف بعض المكررات بشكل مختلف اعتمادًا على ما إذا كان يُقصد بها الإشارة إلى عنصر أو حد بين العناصر. ومن ثمّ، فإن العناصر والحدود مفهومان مختلفان تمامًا. في هذه المناقشة، سوف أقنعك أن المشكلة حقيقية وأن هناك تداعيات مترتبة على استخدامها، وأقدّم اقتراحًا حول كيفية إصلاح ذلك وأوضّح لك كيف أن الحل لا يصلح المشكلة فحسب، بل إنه يساهم في إنشاء تعليمة برمجية أوضح ويمنع من حدوث أخطاء.

---

من المكررات إلى النطاقات — الثورة القادمة في المكتبة القياسية
أرنو شودل

أزواج المكررات واسعة الانتشار في مكتبة C++‎. ومن المسلّم به عمومًا أن دمج هذا الزوج في كيان واحد، يطلق عليه عادةً اسم نطاق، يؤدي إلى إنشاء تعليمة برمجية أوجز وأسهل في القراءة. ولكن يكشف تعريف الدلالات الدقيقة لمفهوم النطاق هذا عن صعوبة مفاجئة بالرغم من ذلك. وتتعارض الاعتبارات النظرية مع العملية. كما أن بعض أهداف التصميم غير متوافقة بشكل متبادل.

---

المنهج العملي في التعامل مع الأخطاء
أرنو شودل

قد يواجه أي برنامج وجود عيوب به، ينشأ بعضها عن أخطاء داخلية في البرنامج، ويحدث بعضها بسبب البيئة التي يتم تشغيل البرنامج فيها. فإذا ما تجاهلنا كل الأخطاء، يصبح البرنامج غير موثوق به تمامًا، بينما يؤدي التعامل مع كل خطأ ممكن إلى ظهور المزيد من التعقيدات مع القليل من المزايا. في شركة think-cell، نستخدم منذ البداية نهجنا القائم على المبادئ في التعامل مع الأخطاء وتحسينه، وهو ما لم نره في أي مكان آخر. تصف هذه المحاضرة أسلوبنا، حتى يكون بإمكانك كتابة برنامج أكثر موثوقية بجهد أقل في مشروعك التالي.

---

حلقة C++ Weekly مقابلة شخصية على CppCast
أرنو شودل

يجري روب إرفينغ وجيسون تيرنر مقابلة شخصية عبر CppCast في 24 يناير 2018 مع أرنو لمناقشة مكتبة نطاقات think-cell وتطوير لغة C++‎ في think-cell بوجه عام.

---

ما مدى صعوبة تطوير وظيفة إضافية بسيطة لبرنامج PowerPoint؟
فالنتين زيغلر

يرتبط تطوير Office على نطاق واسع بوحدات ماكرو VBA المملة، أو JavaScript المبتذلة. وقد تفاجأ العديد من المطورين الذين تحدث إليهم فالنتين فور علمهم بأن قاعدة التعليمات البرمجية لـ think-cells تحتوي على مليون سطر من التعليمات البرمجية للغة البرمجة C++، وأنه يتعين علينا إنشاء بعض المكتبات العامة على طول الطريق لتظل قصيرة إلى هذا الحد. ونحن نسعى جاهدين لتنفيذ أبسط واجهة مستخدم في أعلى برنامج PowerPoint، والتي تمكن المستخدمين من إنشاء شرائح ذات مظهر رائع في وقت قصير، ولهذا نحتاج إلى استخدام أدوات قوية جدًا. دعونا نوضح لكم كيف نطبق أحدث الخوارزميات لحل مشكلات التخطيط وتحديد الموضع، والتحديات التي كان يتعين علينا التغلب عليها لتحقيق التكامل السلس مع التطبيق المضيف.

---

اختراق البرامج القوية
سيمون ماكبارتلين

يعد تصحيح البرامج من الأساليب الفعّالة التي تنطوي على مخاطر محتملة في إصلاح الأخطاء وإضافة وظائف وتحسين سهولة الاستخدام أو أداء البرامج. وتتناول هذه المحاضرة موضوع تصحيح البرامج عند عدم توفر التعليمة البرمجية المصدر، وهذا الإجراء يشار إليه عادةً باسم الاختراق. فنناقش أسباب ضرورة القيام بهذا الإجراء والوقت المناسب لذلك قبل التعمق في تفاصيل تصميم وتنفيذ التصحيحات القوية. وفي الختام، سوف نشرح الأدوات والأساليب المختلفة التي يمكن استخدامها لمعرفة مواضع التصحيح المناسبة.

---

مضى عهد كائنات std::cout — لماذا يجب إيقاف العمل بمكتبة iostream
سيباستيان ثيوفيل

بدأنا مؤخرًا نقل برامجنا إلى أنظمة أساسية أخرى. واكتشفنا أثناء هذه العملية أن المعاناة التي تسببتها مكتبة iostream وكائنات الخرج والدخل من النمط C. وفي هذه المحادثة، نلقي نظرة عامة موجزة عن سبب استبعادنا لمكتبة iostream من التعليمات البرمجية والبديل الذي استخدمناه.

---

نموذج ذاكرة C++‎
فالنتين زيغلر وفابيو فراكاسي

يحدد نموذج الذاكرة C++‎ كيفية تفاعل سلاسل التعليمات المتعددة مع الذاكرة والبيانات المشتركة، مما يتيح للمطورين معرفة التعليمة البرمجية المتزامنة بطريقة مستقلة عن النظام الأساسي. تلقي المحاضرة بالضوء على عمليات التنفيذ متعددة السلاسل وحالات التسابق في لغة C++‎، وكيفية تأثر التعليمة البرمجية المتزامنة بالمحول البرمجي وتحسينات البرامج، وكيفية تجنب السلوك غير المعروف من خلال استخدام أقفال وعمليات ذرية. ثم تركّز المحاضرة على ترتيبات الذاكرة المختلفة للعمليات الذرية، والضمانات، وآثار ذلك على الأداء.

---

C++ في مقابل Java
فالنتين زيغلر وفابيو فراكاسي

نفضل لغة C++‎ ونستخدمها يوميًا. سوف نوضّح في هذه المحاضرة لماذا لغة C++‎ – بالرغم من شهرتها بأنها لغة معقدة – أفضل من الناحية النظرية من لغة Java. لماذا؟ لأن C++‎ تتعرف على دلالات القيم. لأن C++‎ تتمتع بسلوك غير معروف. لأن C++‎ لا تفرض تجميع البيانات المهملة. لأنه يمكننا كتابة تعليمة برمجية باستخدام لغة C++‎ تكون مجرّدة وفعّالة.

---

المنشورات العلمية

خوارزمية فعالة لتسمية المخططات المبعثرة
سيباستيان ثيوفيل وأرنو شودل
وقائع مؤتمر رابطة تطوير الذكاء الاصطناعي AAAI ‏2006

يستعرض هذا البحث الخوارزمية الفعّالة للتغير الجديد في مشكلة تسمية ميزات النقاط. ويتمثل هذا الهدف في وضع أكبر عدد من تسميات النقاط بحيث لا تتداخل مع بعضها البعض أو مع النقاط. ونقدم أولاً خوارزمية باستخدام خوارزمية جشعة ذات توقعات محدودة. ثم نقدم خوارزمية تعمل على إعادة تجميع التسميات بشكل متكرر، مع استدعاء أول خوارزمية من كل مجموعة، وبالتالي يتم تحديد ترتيب التسميات الأمثل. ويتم استخدام الخوارزمية المقدّمة في المنتجات التجارية لتسمية المخططات، ويوضّح تقييمنا أنها تنشئ نتائج أعلى جودة من تلك المنشأة من خلال خوارزميات التسميات الأخرى.

---

خوارزمية ذكية لتسمية المخططات المبعثرة
سيباستيان مولر وأرنو شودل
وقائع مؤتمر الرسوميات الذكية 2005

يقدّم هذا البحث خوارزمية ذكية تعمل على تسمية المخططات العمودية ومشتقاتها. ولحل المشكلة بفعالية، نقسمها إلى مشكلتين فرعيتين. نقدّم أولاً خوارزمية هندسية لحل مشكلة إيجاد تسمية جيدة بالنسبة إلى تسميات العمود الواحد، وذلك على افتراض أنه تمت تسمية الأعمدة الأخرى من قبل. ثم نقدم استراتيجية للتوصل إلى ترتيب جيد تتم فيه تسمية الأعمدة، على أن يتم استخدام الخوارزمية الأولى بصورة متكررة مع بعض التوقعات المحدودة. وتُستخدم الخوارزمية المقدّمة في المنتجات التجارية لتسمية المخططات، وتم توضيحها عمليًا للتوصل إلى نتائج مرضية.

---

أشكال خوارزميات تجزئة الرسوم البيانية Graphcut: تركيب الصورة والفيديو باستخدام خوارزميات تجزئة الرسوم البيانية
فيفيك كواترا وأرنو شودل وعرفان عيسى وجريج تورك وأرون بوبيك
وقائع مؤتمر SIGGRAPH 2003

نستعرض في هذا البحث خوارزمية جديدة لتركيب هيئات الصور والفيديو. ووفقًا لطريقتنا المتبعة، يتم نقل مواضع التصحيح من عينة صورة أو فيديو ونسخها إلى الإخراج ثم تجميعها معًا بخياطات مثالية لإنشاء إخراج جديد (أكبر عادةً). وبخلاف الأساليب الأخرى، لا يتم اختيار حجم التصحيح مسبقًا، ولكن يستخدم أسلوب تجزئة الرسوم لتحديد منطقة التصحيح المثالية لأي إزاحة معينة بين هيئة الإدخال والإخراج. وعلى عكس البرمجة الديناميكية، ينطبق أسلوب تجزئة الرسوم المستخدم لتحسين الحواف على أي بُعد. ونحن من جانبنا ندرس هذا الأسلوب مع الأبعاد الثنائية والثلاثية بالتحديد لتنفيذ تركيب شكل فيديو بالإضافة إلى تركيب صورة عادي.

---

الرسومات المتحكم فيها لصور الفيديو المتحركة
أرنو شودل وعرفان عيسى
وقائع مؤتمر SCA 2002

نقدّم في هذا البحث نهجًا جديدًا لإنشاء رسومات متحكم فيها لصور الفيديو المتحركة. صور الفيديو المتحركة هي عبارة عن رسومات يتم إنشاؤها من خلال إعادة ترتيب إطارات الفيديو المسجّلة لكائن متحرك. ومع تطبيق طريقتنا، يمكن للمستخدم تحديد الرسومات المتحركة باستخدام دالة تكلفة مرنة، يتم تحسينها تلقائيًا عن طريق الاستبدال المتكرر لمتتاليات صور الفيديو المتحركة.

---

هيئات الفيديو
أرنو شودل وريتشارد سزيلسكي وديفيد إتش سالسين وعرفان عيسى
وقائع مؤتمر SIGGRAPH 2000

يتناول هذا البحث نوعًا جديدًا من الوسائط، يطلق عليه اسم هيئة الفيديو، يتمتع بمميزات متوسطة بين الصورة والفيديو. ويوفر شكل الفيديو تدفقًا متغيرًا ولانهائيًا من الصور المستمرة. وعلى الرغم من احتمال تكرار الإطارات الفردية لإحدى هيئات الفيديو من آن لآخر، لا يتكرر تسلسل الفيديو نهائيًا. ويمكن استخدام هيئات الفيديو بدلاً من الصور الرقمية حتى يتم بث صورة ثابتة بميزات ديناميكية وتأثير واضح.