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