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