مروری بر معماری RenderingNG

Chris Harrelson

توجه: این پست بخشی از مجموعه‌ای از موتور رندر کرومیوم است. برای کسب اطلاعات بیشتر، بقیه سریال ها را ببینید.

در پست قبلی ، مروری بر اهداف معماری RenderingNG و ویژگی های کلیدی ارائه دادم. این پست نحوه تنظیم قطعات اجزای آن و نحوه عبور خط لوله رندر از میان آنها را توضیح می دهد.

با شروع از بالاترین سطح و حفاری از آنجا، وظایف رندر عبارتند از:

1. محتویات را به پیکسل بر روی صفحه نمایش دهید .
2. جلوه های بصری را بر روی محتویات از حالتی به حالت دیگر متحرک کنید .
3. در پاسخ به ورودی اسکرول کنید .
4. ورودی را به طور موثر به مکان های مناسب هدایت کنید تا اسکریپت های توسعه دهنده و سایر سیستم های فرعی بتوانند پاسخ دهند.

محتویاتی که باید رندر شوند درختی از فریم‌ها برای هر برگه مرورگر، به علاوه رابط کاربری مرورگر هستند. و، جریانی از رویدادهای ورودی خام از صفحه نمایش لمسی، ماوس، صفحه کلید و سایر دستگاه های سخت افزاری.

هر فریم شامل:

• وضعیت DOM
• CSS
• بوم های نقاشی
• منابع خارجی مانند تصاویر، ویدئو، فونت و SVG

فریم یک سند HTML به اضافه URL آن است. یک صفحه وب بارگذاری شده در یک برگه مرورگر دارای یک قاب سطح بالا، فریم های فرزند برای هر iframe موجود در سند سطح بالا، و فرزندان iframe بازگشتی آنها است.

جلوه بصری یک عملیات گرافیکی است که بر روی یک بیت مپ اعمال می شود، مانند اسکرول، تبدیل، کلیپ، فیلتر، کدورت یا ترکیب.

اجزای معماری

در RenderingNG، این وظایف به طور منطقی در چندین مرحله و مؤلفه کد تقسیم می شوند. کامپوننت‌ها در فرآیندهای مختلف CPU، رشته‌ها و اجزای فرعی درون آن رشته‌ها ختم می‌شوند. هر کدام نقش مهمی در دستیابی به قابلیت اطمینان ، عملکرد مقیاس پذیر و توسعه پذیری برای تمام محتوای وب دارند.

رندر کردن ساختار خط لوله

رندر در یک خط لوله با تعدادی از مراحل و مصنوعات ایجاد شده در طول مسیر انجام می شود. هر مرحله نشان دهنده کدی است که یک کار به خوبی تعریف شده در رندر انجام می دهد. آرتیفکت ها ساختارهای داده ای هستند که ورودی یا خروجی مراحل هستند. در نمودار ورودی یا خروجی با فلش نشان داده شده است.

این پست وبلاگ به جزئیات زیادی در مورد مصنوعات نمی پردازد. که در پست بعدی مورد بحث قرار خواهد گرفت: ساختارهای داده کلیدی و نقش آنها در RenderingNG .

مراحل خط لوله

در نمودار قبل، مراحل با رنگ‌هایی مشخص می‌شوند که نشان می‌دهند در کدام رشته یا فرآیند اجرا می‌شوند:

• سبز: رندر موضوع اصلی فرآیند
• زرد: رندر ترکیب کننده فرآیند
• نارنجی: یعنی فرآیند

در برخی موارد بسته به شرایط می توانند در چندین مکان اجرا شوند، به همین دلیل است که برخی دو رنگ دارند.

مراحل عبارتند از:

1. Animate: سبک های محاسبه شده را تغییر دهید و درختان ویژگی را در طول زمان بر اساس جدول زمانی اعلامی تغییر دهید.
2. سبک: CSS را در DOM اعمال کنید و سبک های محاسبه شده را ایجاد کنید.
3. Layout: اندازه و موقعیت عناصر DOM را روی صفحه تعیین کنید و درخت قطعه غیرقابل تغییر ایجاد کنید.
4. Pre-paint: درخت‌های ویژگی را محاسبه کنید و لیست‌های نمایشی موجود و کاشی‌های بافت GPU را در صورت لزوم باطل کنید .
5. اسکرول: افست اسکرول اسناد و عناصر DOM قابل پیمایش را با جهش درخت های ویژگی به روز کنید.
6. Paint: یک لیست نمایشی را محاسبه کنید که نحوه رستر کردن کاشی های بافت گرافیکی GPU از DOM را توضیح می دهد.
7. Commit: درختان ویژگی و لیست نمایشگر را در رشته کامپوزیتور کپی کنید.
8. لایه بندی: لیست نمایش را به یک لیست لایه ترکیبی برای شطرنجی سازی و انیمیشن مستقل تقسیم کنید.
9. رستر، کدگشایی و رنگ‌آمیزی: فهرست‌های نمایش، تصاویر رمزگذاری‌شده و کدهای ورکلت را به ترتیب به کاشی‌های بافت GPU تبدیل کنید.
10. فعال کردن: یک قاب ترکیبی ایجاد کنید که نشان دهنده نحوه ترسیم و قرار دادن کاشی های GPU روی صفحه نمایش است، همراه با جلوه های بصری.
11. مجموع: ترکیب فریم‌های ترکیب‌کننده از همه فریم‌های ترکیب‌کننده قابل مشاهده در یک فریم ترکیب‌کننده واحد و جهانی.
12. Draw: فریم ترکیبی را روی GPU اجرا کنید تا پیکسل‌هایی روی صفحه ایجاد کنید.

مراحل خط لوله رندر را می توان در صورت عدم نیاز رد کرد. برای مثال، انیمیشن‌های جلوه‌های بصری، و اسکرول، می‌توانند از طرح‌بندی، پیش‌رنگ‌آمیزی و نقاشی صرف‌نظر کنند. به همین دلیل است که انیمیشن و اسکرول با نقاط زرد و سبز در نمودار مشخص شده اند. اگر بتوان از چیدمان، پیش‌رنگ و رنگ برای جلوه‌های بصری صرفنظر کرد، می‌توان آن‌ها را به‌طور کامل بر روی نخ کامپوزیتور اجرا کرد و از نخ اصلی عبور کرد.

رندر رابط کاربری مرورگر مستقیماً در اینجا نشان داده نمی‌شود، اما می‌توان آن را به‌عنوان یک نسخه ساده‌شده از همین خط لوله در نظر گرفت (و در واقع اجرای آن بیشتر کد را به اشتراک می‌گذارد). ویدئو (همچنین مستقیماً نشان داده نمی‌شود) عموماً از طریق کد مستقلی ارائه می‌شود که فریم‌ها را به کاشی‌های بافت GPU رمزگشایی می‌کند و سپس به فریم‌های ترکیب‌کننده و مرحله ترسیم متصل می‌شوند.

فرآیند و ساختار نخ

توجه: فرآیندها و رشته‌های CPU در معماری Chromium بیشتر از آنچه در اینجا نشان داده شده است وجود دارد. این نمودارها فقط روی آنهایی که برای رندر حیاتی هستند تمرکز دارند.

پردازش های CPU

استفاده از چندین فرآیند CPU باعث می شود عملکرد و امنیت ایزوله بین سایت ها و از وضعیت مرورگر، و پایداری و جداسازی امنیت از سخت افزار GPU ایجاد شود.

• فرآیند رندر رندر، متحرک سازی، اسکرول و مسیرهای ورودی را برای یک سایت و ترکیب برگه واحد می کند. فرآیندهای رندر زیادی وجود دارد.
• فرآیند مرورگر، ورودی را برای رابط کاربری مرورگر (شامل نوار URL، عناوین برگه‌ها و نمادها) رندر می‌کند، متحرک می‌کند، و مسیریابی می‌کند و تمام ورودی‌های باقی‌مانده را به فرآیند رندر مناسب هدایت می‌کند. دقیقاً یک فرآیند مرورگر وجود دارد.
• فرآیند Viz ترکیبی از فرآیندهای رندر متعدد به اضافه فرآیند مرورگر است. با استفاده از GPU رسم و رسم می کند. دقیقا یک فرآیند Viz وجود دارد.

سایت های مختلف همیشه به فرآیندهای رندر متفاوت ختم می شوند. (در واقع، همیشه روی دسکتاپ؛ در صورت امکان در تلفن همراه . من "همیشه" را در زیر می نویسم، اما این هشدار در همه موارد اعمال می شود.)

چندین برگه مرورگر یا پنجره های یک سایت معمولاً در فرآیندهای رندر متفاوتی قرار می گیرند، مگر اینکه تب ها مرتبط باشند (یکی دیگری را باز می کند ). تحت فشار شدید حافظه روی دسک‌تاپ، Chromium ممکن است چندین برگه از یک سایت را در یک فرآیند رندر قرار دهد، حتی اگر مرتبط نباشد.

در یک برگه مرورگر، فریم‌های سایت‌های مختلف همیشه در فرآیندهای رندر متفاوت از یکدیگر قرار دارند، اما فریم‌های یک سایت همیشه در یک فرآیند رندر هستند. از منظر رندر، مزیت مهم فرآیندهای رندر چندگانه این است که iframe ها و تب های متقاطع سایت به جداسازی عملکرد از یکدیگر می رسند. علاوه بر این، ریشه ها می توانند حتی بیشتر در انزوا انتخاب شوند.

دقیقاً یک فرآیند Viz برای همه Chromium وجود دارد. از این گذشته، معمولاً فقط یک پردازنده گرافیکی و صفحه نمایش برای طراحی وجود دارد. جداسازی Viz به فرآیند خودش برای پایداری در مواجهه با اشکالات درایورهای GPU یا سخت افزار خوب است. همچنین برای ایزوله سازی امنیتی خوب است، که برای API های GPU مانند Vulkan مهم است. همچنین برای امنیت به طور کلی مهم است.

از آنجایی که مرورگر می‌تواند تب‌ها و پنجره‌های زیادی داشته باشد و همه آنها دارای پیکسل‌های رابط کاربری مرورگر برای ترسیم هستند، ممکن است تعجب کنید: چرا دقیقاً یک فرآیند مرورگر وجود دارد؟ دلیل آن این است که تنها یکی از آنها در یک زمان متمرکز است. در واقع، تب های غیر قابل مشاهده مرورگر عمدتا غیرفعال می شوند و تمام حافظه GPU خود را حذف می کنند. با این حال، ویژگی های پیچیده رندر رابط کاربری مرورگر به طور فزاینده ای در فرآیندهای رندر نیز اجرا می شوند (معروف به WebUI ). این به دلایل جداسازی عملکرد نیست، بلکه به منظور استفاده از سهولت استفاده از موتور رندر وب Chromium است.

در دستگاه‌های Android قدیمی‌تر ، فرآیند رندر و مرورگر زمانی که در WebView استفاده می‌شود به اشتراک گذاشته می‌شود (این به طور کلی برای Chromium در Android اعمال نمی‌شود، فقط WebView). در WebView، فرآیند مرورگر نیز با برنامه جاسازی به اشتراک گذاشته می‌شود و WebView تنها یک فرآیند رندر دارد.

همچنین گاهی اوقات یک فرآیند کاربردی برای رمزگشایی محتوای ویدیویی محافظت شده وجود دارد. این فرآیند در بالا نشان داده نشده است.

موضوعات

موضوعات به دستیابی به انزوای عملکرد و پاسخگویی با وجود انجام وظایف کند، موازی سازی خط لوله و بافر چندگانه کمک می کنند.

• رشته اصلی اسکریپت ها، حلقه رویداد رندر، چرخه عمر سند، تست ضربه، ارسال رویداد اسکریپت، و تجزیه HTML، CSS و سایر فرمت های داده را اجرا می کند.
  • کمک کننده های رشته اصلی کارهایی مانند ایجاد بیت مپ های تصویر و حباب هایی که نیاز به رمزگذاری یا رمزگشایی دارند را انجام می دهند.
  • Web Workers اسکریپت و یک حلقه رویداد رندر برای OffscreenCanvas را اجرا می کنند.
• رشته Compositor رویدادهای ورودی را پردازش می‌کند، پیمایش و انیمیشن‌های محتوای وب را انجام می‌دهد، لایه‌بندی بهینه محتوای وب را محاسبه می‌کند و رمزگشایی‌های تصویر، Worklet‌های نقاشی و وظایف شطرنجی را هماهنگ می‌کند.
  • کمک‌کننده‌های رشته Compositor وظایف شطرنجی Viz را هماهنگ می‌کنند، و وظایف رمزگشایی تصویر، worklets رنگ و رستر بازگشتی را اجرا می‌کنند.
• رسانه ها، دموکسر یا رشته های خروجی صدا جریان های ویدئویی و صوتی را رمزگشایی، پردازش و همگام سازی می کنند. (به یاد داشته باشید که ویدئو به موازات خط لوله رندر اصلی اجرا می شود.)

جداسازی رشته‌های اصلی و ترکیب‌کننده برای جداسازی عملکرد انیمیشن و اسکرول از کار رشته اصلی بسیار مهم است.

در هر فرآیند رندر فقط یک رشته اصلی وجود دارد، حتی اگر چندین برگه یا فریم از یک سایت ممکن است به یک فرآیند ختم شوند. با این حال، جداسازی عملکرد از کارهای انجام شده در API های مختلف مرورگر وجود دارد. به عنوان مثال، تولید بیت مپ ها و حباب های تصویر در Canvas API در یک رشته کمکی رشته اصلی اجرا می شود.

به همین ترتیب، در هر فرآیند رندر تنها یک رشته ترکیبی وجود دارد. به طور کلی مشکلی نیست که فقط یک مورد وجود داشته باشد، زیرا تمام عملیات واقعاً گران روی رشته کامپوزیتور به رشته‌های کارگر کامپوزیتور یا فرآیند Viz واگذار می‌شود و این کار را می‌توان به موازات مسیریابی ورودی، اسکرول یا انیمیشن انجام داد. . وظایف هماهنگی threads کارگر Compositor در فرآیند Viz اجرا می‌شود، اما شتاب GPU در همه جا ممکن است به دلایلی خارج از کنترل Chromium، مانند اشکالات درایور، با شکست مواجه شود. در این مواقع، Worker Thread کار را در حالت بازگشتی روی CPU انجام می دهد.

تعداد نخ های کامپوزیتور کارگر بستگی به قابلیت های دستگاه دارد. برای مثال، دسک‌تاپ‌ها معمولاً از Thread‌های بیشتری استفاده می‌کنند، زیرا هسته‌های CPU بیشتری دارند و نسبت به دستگاه‌های تلفن همراه باتری کمتری دارند. این نمونه ای از افزایش و کاهش مقیاس است.

همچنین جالب است بدانیم که معماری رشته‌بندی فرآیند رندر، کاربرد سه الگوی مختلف بهینه‌سازی است:

• رشته‌های کمکی: ارسال وظایف فرعی طولانی‌مدت به رشته‌های اضافی، برای پاسخگویی موضوع اصلی به درخواست‌های دیگر که به طور همزمان انجام می‌شوند. نخ های کمکی اصلی و رزوه های کمکی ترکیب کننده نمونه های خوبی از این تکنیک هستند.
• بافر چندگانه : نمایش محتوای رندر شده قبلی در حین ارائه محتوای جدید، برای پنهان کردن تأخیر رندر. رشته کامپوزیتور از این تکنیک استفاده می کند.
• موازی سازی خط لوله: اجرای خط لوله رندر در چندین مکان به طور همزمان. به این ترتیب اسکرول و انیمیشن می توانند سریع باشند، حتی اگر یک به روز رسانی رندر رشته اصلی اتفاق بیفتد، زیرا اسکرول و انیمیشن می توانند به صورت موازی اجرا شوند.

فرآیند مرورگر

• رشته رندر و ترکیب به ورودی در UI مرورگر پاسخ می دهد، ورودی های دیگر را به فرآیند رندر صحیح هدایت می کند. رابط کاربری مرورگر را طراحی و نقاشی می کند.
• کمک‌کننده‌های رشته‌های رندر و ترکیب، وظایف رمزگشایی تصویر و رستر یا رمزگشایی مجدد را اجرا می‌کنند.

رندر فرآیند مرورگر و رشته ترکیبی شبیه به کد و عملکرد یک فرآیند رندر هستند، با این تفاوت که رشته اصلی و رشته کامپوزیتور در یکی ترکیب می شوند. در این مورد فقط یک رشته مورد نیاز است زیرا نیازی به جداسازی عملکرد از وظایف نخ اصلی طولانی نیست، زیرا هیچ کدام از نظر طراحی وجود ندارد.

یعنی فرآیند

• شطرنج‌های رشته اصلی GPU فهرست‌ها و فریم‌های ویدیویی را در کاشی‌های بافت GPU نمایش می‌دهند و فریم‌های ترکیب‌کننده را به صفحه می‌کشند.
• رشته کامپوزیتور نمایشگر ، ترکیب را از هر فرآیند رندر، به‌علاوه فرآیند مرورگر، در یک فریم ترکیب‌کننده واحد برای ارائه به صفحه جمع‌بندی و بهینه‌سازی می‌کند.

رستر و ترسیم عموماً روی یک رشته اتفاق می‌افتند، زیرا هر دوی آنها به منابع GPU متکی هستند و استفاده قابل اعتماد چند رشته‌ای از GPU دشوار است (دسترسی آسان‌تر چند رشته‌ای به GPU یکی از انگیزه‌های توسعه استاندارد جدید Vulkan است. ). در Android WebView، به دلیل نحوه تعبیه WebViewها در یک برنامه بومی، یک رشته رندر در سطح سیستم عامل جداگانه برای طراحی وجود دارد. سایر پلتفرم ها احتمالاً در آینده چنین موضوعی خواهند داشت.

سازنده نمایشگر در رشته دیگری قرار دارد زیرا باید همیشه پاسخگو باشد و هیچ منبع احتمالی کاهش سرعت در رشته اصلی GPU را مسدود نکند. یکی از دلایل کاهش سرعت در رشته اصلی GPU، فراخوانی به کدهای غیر Chromium، مانند درایورهای GPU خاص فروشنده است، که ممکن است به روش‌های غیرقابل پیش‌بینی کند باشند.

ساختار جزء

در هر رشته اصلی یا کامپوزیتور فرآیند رندر، اجزای نرم‌افزار منطقی وجود دارد که به روش‌های ساختاریافته با یکدیگر تعامل دارند.

رندر اجزای رشته اصلی فرآیند

• رندر چشمک زدن:
  • قطعه درخت قاب محلی نشان دهنده درخت فریم های محلی و DOM درون فریم ها است.
  • مؤلفه DOM و Canvas APIها شامل پیاده سازی همه این APIها است.
  • اجرا کننده چرخه حیات سند، مراحل رندر خط لوله را تا مرحله commit و از جمله آن اجرا می کند.
  • مؤلفه آزمایش و ارسال ضربه رویداد ورودی، آزمایش‌های ضربه را اجرا می‌کند تا بفهمد کدام عنصر DOM توسط یک رویداد هدف قرار گرفته است، و الگوریتم‌های ارسال رویداد ورودی و رفتارهای پیش‌فرض را اجرا می‌کند.
• زمان‌بندی و اجراکننده حلقه رویداد رندر تصمیم می‌گیرد چه چیزی و چه زمانی در حلقه رویداد اجرا شود. برنامه ریزی می کند که رندر در آهنگی مطابق با نمایشگر دستگاه اتفاق بیفتد.

تکه های درخت قاب محلی کمی پیچیده است. به یاد بیاورید که درخت فریم صفحه اصلی و فریم های فرزند آن به صورت بازگشتی است. یک فریم اگر در آن فرآیند رندر شود، محلی برای یک فرآیند رندر است و در غیر این صورت راه دور است.

می توانید رنگ آمیزی فریم ها را با توجه به فرآیند رندر آنها تصور کنید. در تصویر قبل، دایره‌های سبز رنگ همگی فریم‌هایی در یک فرآیند رندر هستند. رنگ های نارنجی در یک ثانیه و آبی در یک سوم قرار دارند.

قطعه درخت قاب محلی یک جزء متصل از همان رنگ در یک درخت قاب است. چهار درخت فریم محلی در تصویر وجود دارد: دو درخت برای سایت A، یکی برای سایت B، و یکی برای سایت C. هر درخت فریم محلی جزء رندر Blink خود را دریافت می کند. رندر Blink یک درخت فریم محلی ممکن است در فرآیند رندر مشابه با سایر درختان فریم محلی باشد یا نباشد (که با نحوه انتخاب فرآیندهای رندر مشخص می شود، همانطور که قبلا توضیح داده شد).

رندر ساختار نخ کامپوزیتور فرآیند

اجزای سازنده فرآیند رندر عبارتند از:

• یک کنترل کننده داده که یک لیست لایه های ترکیبی، لیست های نمایشی و درختان ویژگی را نگهداری می کند.
• یک دونده چرخه حیات که مراحل متحرک سازی، اسکرول، ترکیبی، شطرنجی و رمزگشایی و فعال سازی مراحل خط لوله رندر را اجرا می کند. (به یاد داشته باشید که متحرک سازی و اسکرول می توانند هم در رشته اصلی و هم در آهنگساز رخ دهند.)
• یک کنترل‌کننده تست ورودی و ضربه، پردازش ورودی و تست ضربه را با وضوح لایه‌های ترکیبی انجام می‌دهد تا تعیین کند آیا حرکات اسکرول را می‌توان روی رشته ترکیب‌کننده اجرا کرد، و کدام آزمون‌های ضربه فرآیند رندر را باید هدف قرار دهند.

یک مثال در عمل

اکنون با یک مثال معماری را بتن می کنیم. در این مثال سه تب وجود دارد:

برگه 1: foo.com

<html>
  <iframe id=one src="foo.com/other-url"></iframe>
  <iframe  id=two src="bar.com"></iframe>
</html>

برگه 2: bar.com

<html>
 …
</html>

برگه 3: baz.com html <html> … </html>

فرآیند، رشته و ساختار اجزای این تب ها به شکل زیر خواهد بود:

حال بیایید هر یک از چهار کار اصلی رندر را با یک مثال مرور کنیم، که ممکن است به یاد داشته باشید:

1. محتویات را به پیکسل بر روی صفحه نمایش دهید .
2. جلوه های بصری را بر روی محتویات از حالتی به حالت دیگر متحرک کنید .
3. در پاسخ به ورودی اسکرول کنید .
4. ورودی را به طور موثر به مکان های مناسب هدایت کنید تا اسکریپت های توسعه دهنده و سایر سیستم های فرعی بتوانند پاسخ دهند.

برای ارائه DOM تغییر یافته برای تب یک:

1. یک اسکریپت توسعه دهنده DOM را در فرآیند رندر برای foo.com تغییر می دهد.
2. رندر Blink به کامپوزیتور می گوید که برای رخ دادن نیاز به رندر دارد.
3. کامپوزیتور به Viz می گوید که برای رخ دادن به یک رندر نیاز دارد.
4. Viz شروع رندر را به کامپوزیتور سیگنال می دهد.
5. کامپوزیتور سیگنال شروع را به رندر Blink ارسال می کند.
6. اجراکننده حلقه رویداد رشته اصلی چرخه عمر سند را اجرا می کند.
7. نخ اصلی نتیجه را به رشته کامپوزیتور ارسال می کند.
8. اجراکننده حلقه رویداد کامپوزیتور چرخه حیات ترکیب را اجرا می کند.
9. هر کار شطرنجی برای رستر به Viz ارسال می شود (اغلب بیش از یکی از این وظایف وجود دارد).
10. یعنی محتوای رسترها در GPU.
11. Viz تکمیل کار شطرنجی را تأیید می کند. توجه: Chromium اغلب منتظر نمی ماند تا رستر کامل شود، و در عوض از چیزی به نام نشانه همگام سازی استفاده می کند که باید قبل از اجرای مرحله 15 توسط وظایف شطرنجی حل شود.
12. یک فریم کامپوزیتور به Viz ارسال می شود.
13. Viz فریم های کامپوزیتور را برای فرآیند رندر foo.com، فرآیند رندر iframe bar.com و رابط کاربری مرورگر را جمع می کند.
14. ویز قرعه کشی را برنامه ریزی می کند.
15. به عنوان مثال، قاب ترکیب‌کننده جمع‌آوری شده را روی صفحه می‌کشد.

برای متحرک سازی یک انتقال تبدیل CSS در برگه دو:

1. رشته کامپوزیتور برای فرآیند رندر bar.com یک انیمیشن را در حلقه رویداد کامپوزیتور خود با جهش درخت های ویژگی موجود علامت می دهد. سپس چرخه عمر کامپوزیتور را دوباره اجرا می کند. (کارهای رستر و رمزگشایی ممکن است رخ دهند، اما در اینجا به تصویر کشیده نشده اند.)
2. یک فریم کامپوزیتور به Viz ارسال می شود.
3. Viz فریم های کامپوزیتور را برای فرآیند رندر foo.com، فرآیند رندر bar.com و رابط کاربری مرورگر جمع می کند.
4. ویز قرعه کشی را برنامه ریزی می کند.
5. به عنوان مثال، قاب ترکیب‌کننده جمع‌آوری شده را روی صفحه می‌کشد.

برای پیمایش صفحه وب در برگه سه:

1. دنباله ای از رویدادهای input (ماوس، لمس یا صفحه کلید) به فرآیند مرورگر می آیند.
2. هر رویداد به رشته ترکیب‌کننده فرآیند رندر baz.com هدایت می‌شود.
3. ترکیب کننده تعیین می کند که آیا موضوع اصلی باید درباره رویداد بداند یا خیر.
4. رویداد در صورت لزوم به موضوع اصلی ارسال می شود.
5. رشته اصلی شنوندگان رویداد input ( pointerdown ، touchstar ، pointermove ، touchmove یا wheel ) را فعال می کند تا ببیند آیا شنوندگان در رویداد، preventDefault فرا خواهند خواند.
6. رشته اصلی نشان می دهد که آیا preventDefault به کامپوزیتور فراخوانی شده است یا خیر.
7. در غیر این صورت، رویداد ورودی به فرآیند مرورگر بازگردانده می شود.
8. فرآیند مرورگر با ترکیب آن با سایر رویدادهای اخیر، آن را به یک حرکت حرکتی تبدیل می‌کند.
9. ژست اسکرول یک بار دیگر به رشته ترکیب کننده فرآیند رندر baz.com ارسال می شود.
10. اسکرول در آنجا اعمال می‌شود، و رشته ترکیب‌کننده برای فرآیند رندر bar.com یک انیمیشن را در حلقه رویداد ترکیب‌کننده آن علامت‌گذاری می‌کند. سپس این اسکرول افست را در درخت های ویژگی تغییر می دهد و چرخه حیات کامپوزیتور را دوباره اجرا می کند. همچنین به رشته اصلی می‌گوید که یک رویداد scroll را اجرا کند (در اینجا نشان داده نشده است).
11. یک فریم کامپوزیتور به Viz ارسال می شود.
12. Viz فریم های کامپوزیتور را برای فرآیند رندر foo.com، فرآیند رندر bar.com و رابط کاربری مرورگر جمع می کند.
13. ویز قرعه کشی را برنامه ریزی می کند.
14. به عنوان مثال، قاب ترکیب‌کننده جمع‌آوری شده را روی صفحه می‌کشد.

توجه: توجه داشته باشید که هر رویداد ورودی بعد از اولین می‌تواند مراحل سه و چهار را رد کند، زیرا پیمایش قبلاً شروع شده است و در آن نقطه اسکریپت‌ها می‌توانند آن را از طریق رویداد scroll مشاهده کنند، اما دیگر قطع نکنند.

برای مسیریابی یک رویداد click روی یک پیوند در iframe #two در تب یک:

1. یک رویداد input (موس، لمسی یا صفحه کلید) به فرآیند مرورگر می آید. یک تست ضربه تقریبی انجام می دهد تا مشخص کند که فرآیند رندر iframe bar.com باید کلیک را دریافت کند و آن را به آنجا ارسال می کند.
2. رشته compositor برای bar.com رویداد click را به رشته اصلی bar.com هدایت می کند و یک کار حلقه رویداد رندر را برای پردازش آن زمان بندی می کند.
3. پردازشگر رویداد ورودی برای رشته اصلی bar.com تست می کند تا مشخص کند کدام عنصر DOM در iframe کلیک شده است و یک رویداد click را برای مشاهده اسکریپت ها فعال می کند. با شنیدن هیچ preventDefault ، به لینک هدایت می شود.
4. پس از بارگذاری صفحه مقصد لینک، وضعیت جدید با مراحلی شبیه به مثال "رندر تغییر DOM" در بالا ارائه می شود. (این تغییرات بعدی در اینجا نشان داده نشده است.)

نتیجه

اوه، این جزئیات زیادی بود. همانطور که می بینید، رندر در Chromium بسیار پیچیده است! یادآوری و درونی کردن تمام قطعات ممکن است زمان زیادی ببرد، بنابراین اگر به نظر طاقت فرسا به نظر می رسد نگران نباشید.

مهمترین نکته این است که یک خط لوله رندر مفهومی ساده وجود دارد که از طریق مدولارسازی دقیق و توجه به جزئیات، به تعدادی از اجزای مستقل تقسیم شده است. سپس این مؤلفه‌ها در بین فرآیندها و رشته‌های موازی تقسیم شده‌اند تا عملکرد مقیاس‌پذیر و فرصت‌های توسعه‌پذیری را به حداکثر برسانند.

هر یک از این مؤلفه ها نقش مهمی در فعال کردن همه عملکردها و ویژگی های مورد نیاز برنامه های وب مدرن دارند. به زودی ما در مورد هر یک از آنها و نقش های مهمی که ایفا می کنند، اطلاعات عمیقی را منتشر خواهیم کرد.

اما قبل از آن، من همچنین توضیح خواهم داد که چگونه ساختارهای داده کلیدی ذکر شده در این پست (آنهایی که با رنگ آبی در کناره‌های نمودار خط لوله رندر نشان داده شده‌اند) به اندازه اجزای کد برای RenderingNG مهم هستند.

ممنون که خواندید و منتظر باشید!

تصاویر توسط Una Kravets.