מלחין חומרה HAL

HAL Hardware Composer (HWC) HAL קובע את הדרך היעילה ביותר לחיבור מאגרים עם החומרה הזמינה. כ- HAL, היישום שלה הוא ספציפי למכשיר ובדרך כלל נעשה על ידי OEM חומרת התצוגה.

הערך של גישה זו הוא קל לזהות מתי אתה מחשיב כיסוי מטוסים, אשר מאגרים מרובים מרוכבים בחומרה לתצוגה ולא GPU. לדוגמה, שקול טלפון אנדרואיד טיפוסי בכיוון דיוקן, כאשר שורת המצב למעלה, סרגל הניווט בתחתית ותוכן האפליקציות בכל מקום אחר. התוכן עבור כל שכבה נמצא במאגרים נפרדים. אתה יכול להתמודד עם הרכב באמצעות אחת מהשיטות הבאות:

  • עיבוד תוכן האפליקציה למאגר שריטות, ולאחר מכן עיבוד שורת המצב מעליו, סרגל הניווט על גבי זה, ולבסוף העברת מאגר השריטות לחומרת התצוגה.
  • העברת כל שלושת המאגרים לחומרת התצוגה והוראתה לקרוא נתונים ממאגרים שונים עבור חלקים שונים של המסך.

הגישה האחרונה יכולה להיות יעילה יותר באופן משמעותי.

יכולות מעבד התצוגה משתנות באופן משמעותי. מספר השכבות, בין אם ניתן לסובב או לערבב שכבות, והגבלות על מיקום וחפיפה יכולות להיות קשות לביטוי באמצעות API. כדי להתאים לאפשרויות אלה, ה- HWC מבצע את החישובים הבאים:

  1. SurfaceFlinger מספק ל- HWC רשימה מלאה של שכבות ושואל: "איך אתה רוצה להתמודד עם זה?"
  2. HWC מגיב על ידי סימון כל שכבה כהרכב מכשיר או לקוח.
  3. SurfaceFlinger מטפל בכל לקוח, מעביר את מאגר הפלט ל- HWC ומאפשר ל- HWC להתמודד עם כל השאר.

מכיוון שספקי חומרה יכולים להתאים אישית קוד קבלת החלטות בהתאמה אישית, ניתן להפיק את הביצועים הטובים ביותר מכל מכשיר.

מטוסי כיסוי עשויים להיות פחות יעילים בהרכב GL כאשר שום דבר על המסך אינו משתנה. הדבר נכון במיוחד כאשר לתוכן שכבת -על יש פיקסלים שקופים ושכבות חופפות מעורבבות. במקרים כאלה, HWC יכול לבקש הרכב GLES עבור כמה או כל השכבות ולשמור על המאגר המורכב. אם SurfaceFlinger מבקש להרכיב את אותה קבוצת מאגרים, ה- HWC יכול להציג את מאגר השריטות שהורכב בעבר. זה יכול לשפר את חיי הסוללה של התקן סרק.

מכשירי Android תומכים בדרך כלל בארבעה מטוסי שכבה. ניסיון להרכיב יותר שכבות מאשר שכבות -על גורם למערכת להשתמש בהרכב GLES עבור חלק מהן, כלומר למספר השכבות בהן משתמשת אפליקציה יכולה להיות השפעה ניתנת למדידה על צריכת החשמל והביצועים.