مدیریت فریم بافر مشتری

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

مدیریت فریم بافر در هنگام سوئیچ وضوح

تغییرات وضوح به دلیل یکی از دو سناریو زیر رخ می دهد:

  • یک رویداد hotplug ، که توسط Hardware Composer (HWC) آغاز شده است، که هنگام جابجایی از یک نمایشگر خارجی به یک صفحه نمایش خارجی متفاوت که وضوح پیش فرض متفاوتی دارد، رخ می دهد.

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

  • یک سوئیچ حالت نمایش که توسط SurfaceFlinger راه اندازی شده است، که زمانی رخ می دهد که کاربر وضوح تصویر را با تنظیمات کاربر تغییر می دهد، یا یک برنامه وضوح را با preferredDisplayModeId تغییر می دهد.

    در طی یک سوئیچ حالت نمایش، دسته‌های فریم بافرهای مشتری موجود قبل از فراخوانی setActiveConfig یا setActiveConfigWithConstraints توسط SurfaceFlinger آزاد می‌شوند.

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

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

توصیه هایی برای مدیریت فریم بافر

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

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

  • اگر HWC نیاز به استفاده از فریم بافرهای مشتری قدیمی تا زمانی که فریم بافرهای کلاینت جدید ارائه شود، ادامه دهد، مهم است که حافظه کافی برای فریم بافرهای قدیمی و جدید ذخیره کنید و احتمالاً الگوریتم های یکپارچه سازی را در فضای حافظه فریم بافر اجرا کنید.

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

تست مدیریت فریم بافر

به OEM ها توصیه می شود که مدیریت مناسب حافظه فریم بافر کلاینت را در سراسر سوئیچ های وضوح دستگاه خود آزمایش کنند که به شرح زیر است:

  • برای رویدادهای hotplug، به سادگی دو نمایشگر مختلف با وضوح متفاوت را جدا کرده و دوباره وصل کنید.

  • برای سوئیچ‌های حالت، از تست ModeSwitchingTestActivity CTS Verifier برای شروع یک سوئیچ حالت برای آزمایش رفتار حافظه فریم بافر استفاده کنید. این تست می‌تواند مشکلاتی را که به سختی قابل تشخیص هستند، شناسایی کند.

،

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

مدیریت فریم بافر در هنگام سوئیچ وضوح

تغییرات وضوح به دلیل یکی از دو سناریو زیر رخ می دهد:

  • یک رویداد hotplug ، که توسط Hardware Composer (HWC) آغاز شده است، که هنگام جابجایی از یک نمایشگر خارجی به یک صفحه نمایش خارجی متفاوت که وضوح پیش فرض متفاوتی دارد، رخ می دهد.

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

  • یک سوئیچ حالت نمایش که توسط SurfaceFlinger راه اندازی شده است، که زمانی رخ می دهد که کاربر وضوح تصویر را با تنظیمات کاربر تغییر می دهد، یا یک برنامه وضوح را با preferredDisplayModeId تغییر می دهد.

    در طی یک سوئیچ حالت نمایش، دسته‌های فریم بافرهای مشتری موجود قبل از فراخوانی setActiveConfig یا setActiveConfigWithConstraints توسط SurfaceFlinger آزاد می‌شوند.

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

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

توصیه هایی برای مدیریت فریم بافر

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

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

  • اگر HWC نیاز به استفاده از فریم بافرهای مشتری قدیمی تا زمانی که فریم بافرهای کلاینت جدید ارائه شود، ادامه دهد، مهم است که حافظه کافی برای فریم بافرهای قدیمی و جدید ذخیره کنید و احتمالاً الگوریتم های یکپارچه سازی را در فضای حافظه فریم بافر اجرا کنید.

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

تست مدیریت فریم بافر

به OEM ها توصیه می شود که مدیریت مناسب حافظه فریم بافر کلاینت را در سراسر سوئیچ های وضوح دستگاه خود آزمایش کنند که به شرح زیر است:

  • برای رویدادهای hotplug، به سادگی دو نمایشگر مختلف با وضوح متفاوت را جدا کرده و دوباره وصل کنید.

  • برای سوئیچ‌های حالت، از تست ModeSwitchingTestActivity CTS Verifier برای شروع یک سوئیچ حالت برای آزمایش رفتار حافظه فریم بافر استفاده کنید. این تست می‌تواند مشکلاتی را که به سختی قابل تشخیص هستند، شناسایی کند.

،

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

مدیریت فریم بافر در هنگام سوئیچ وضوح

تغییرات وضوح به دلیل یکی از دو سناریو زیر رخ می دهد:

  • یک رویداد hotplug ، که توسط Hardware Composer (HWC) آغاز شده است، که هنگام جابجایی از یک نمایشگر خارجی به یک صفحه نمایش خارجی متفاوت که وضوح پیش فرض متفاوتی دارد، رخ می دهد.

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

  • یک سوئیچ حالت نمایش که توسط SurfaceFlinger راه اندازی شده است، که زمانی رخ می دهد که کاربر وضوح تصویر را با تنظیمات کاربر تغییر می دهد، یا یک برنامه وضوح را با preferredDisplayModeId تغییر می دهد.

    در طی یک سوئیچ حالت نمایش، دسته‌های فریم بافرهای مشتری موجود قبل از فراخوانی setActiveConfig یا setActiveConfigWithConstraints توسط SurfaceFlinger آزاد می‌شوند.

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

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

توصیه هایی برای مدیریت فریم بافر

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

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

  • اگر HWC نیاز به استفاده از فریم بافرهای مشتری قدیمی تا زمانی که فریم بافرهای کلاینت جدید ارائه شود، ادامه دهد، مهم است که حافظه کافی برای فریم بافرهای قدیمی و جدید ذخیره کنید و احتمالاً الگوریتم های یکپارچه سازی را در فضای حافظه فریم بافر اجرا کنید.

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

تست مدیریت فریم بافر

به OEM ها توصیه می شود که مدیریت مناسب حافظه فریم بافر کلاینت را در سراسر سوئیچ های وضوح دستگاه خود آزمایش کنند که به شرح زیر است:

  • برای رویدادهای hotplug، به سادگی دو نمایشگر مختلف با وضوح متفاوت را جدا کرده و دوباره وصل کنید.

  • برای سوئیچ‌های حالت، از تست ModeSwitchingTestActivity CTS Verifier برای شروع یک سوئیچ حالت برای آزمایش رفتار حافظه فریم بافر استفاده کنید. این تست می‌تواند مشکلاتی را که به سختی قابل تشخیص هستند، شناسایی کند.