ה-HAL של Hardware Composer (HWC) קובע את הדרך היעילה ביותר לשילוב מאגרים עם החומרה הזמינה. כ-HAL, ההטמעה שלו ספציפית למכשיר, ובדרך כלל מתבצעת על ידי יצרן הציוד המקורי (OEM) של חומרת התצוגה.
קל להבין את הערך של הגישה הזו כשמדברים על שכבות-על, שבהן נעשה שילוב של מספר מאגרים בחומרת המסך ולא ב-GPU. לדוגמה, ניקח טלפון Android טיפוסי בכיוון לאורך, שבו שורת הסטטוס נמצאת בחלק העליון, סרגל הניווט בחלק התחתון ותוכן האפליקציה בכל שאר המקומות. התוכן של כל שכבה נמצא במאגרים נפרדים. אפשר לטפל בהרכבה באחת מהשיטות הבאות:
- עיבוד תוכן האפליקציה למאגר שריטות, ואז עיבוד סרגל הסטטוס מעליו, סרגל הניווט מעליו, ובסוף העברת מאגר השריטה לחומרת המסך.
- העברת כל שלושת המאגרים לחומרת המסך והוראה לו לקרוא נתונים ממאגרים שונים לחלקים שונים של המסך.
הגישה השנייה יכולה להיות יעילה יותר באופן משמעותי.
היכולות של מעבדי המסך משתנות משמעותית. מספר שכבות-העל, אם אפשר להחליף או למזג את השכבות, וקשה לבטא את הגבלות המיקום והחפיפה באמצעות API. כדי להתאים את האפשרויות האלה, ה-HWC מבצע את החישובים הבאים:
- SurfaceFlinger מספק ל-HWC רשימה מלאה של השכבות ומבקש: "איך רוצים לטפל בזה?"
- התגובה של HWC היא סימון כל שכבה כהרכב של מכשיר או לקוח.
- SurfaceFlinger מטפל בכל לקוח, מעביר את מאגר הפלט ל-HWC ומאפשר ל-HWC לטפל בשאר.
מכיוון שספקי החומרה יכולים להתאים אישית את הקוד לקבלת החלטות, אפשר לקבל את הביצועים הטובים ביותר מכל מכשיר.
מישורי שכבת-על עשויים להיות פחות יעילים מחיבור GL כששום דבר לא משתנה במסך. הדבר נכון במיוחד כשהתוכן של שכבת-העל כולל פיקסלים שקופים ושכבות חופפות ממוזגות. במקרים כאלה, צוות HWC יכול לבקש הרכבה של GLES לחלק מהשכבות או לכולן, ולשמור את מאגר הנתונים הזמני. אם SurfaceFlinger מבקש לשלב את אותה קבוצה של מאגרים, ה-HWC יכול להציג את מאגר הגירוד שעבר שילוב קודם. הפעולה הזו יכולה לשפר את חיי הסוללה של מכשיר במצב מנוחה.
בדרך כלל, מכשירי Android תומכים בארבעה מישורי שכבת-על. ניסיון ליצור קומפוזיציה של יותר שכבות מאשר שכבות-על גורם למערכת להשתמש ב-GLES compositing בחלק מהן. כלומר, מספר השכבות שבהן האפליקציה משתמשת יכול להשפיע באופן מדיד על צריכת החשמל והביצועים.