THotPDF.RenderLoadedPagesParallel Method

מעביר הידור display-list ונגינה שלה ב-pipeline על פני workers מוגבלים, תוך שמירה על סדר הקלט במערך הפלט

הצהרה

function RenderLoadedPagesParallel(const PageIndices: array of Integer;
    DPI, MaxConcurrency: Integer; out Bitmaps: THPDFBitmapArray): Integer; overload;

function RenderLoadedPagesParallel(const PageIndices: array of Integer;
    DPI, MaxConcurrency: Integer; out Bitmaps: THPDFBitmapArray;
    out Info: THPDFParallelRenderPipelineInfo): Integer; overload;

התנהגות

ההידור רץ מחוץ ל-lock של ה-display-list cache, ולכן עמודים לא קשורים יכולים לעבור הידור במקביל, והעמוד הראשון שמוכן יכול להתחיל להתרנדר לפני שכל קבוצת הקלט עברה הידור

ה-scheduler מאזן באופן דינמי בין עבודת הידור לנגינה, מגביל workers ל-MaxConcurrency, מבודד את מצב ה-renderer לכל worker, ומשתף רשומות cache דרך מוני שימוש מוגנים

כאשר PeakMemorySchedulerEnabled הוא true, מספר ה-workers בפועל מוקטן מהבקשה המנורמלת לפי הערכת העמוד הגדולה ביותר והתקציב הגלובלי הזמין כרגע, ואז כל עמוד שנתבע מחזיק הזמנת זיכרון הוגנת משלו לאורך ההידור והנגינה

ה-overload עם Info מדווח על workers מבוקשים ובפועל, על מגבלת workers שנגזרה מהזיכרון, על הערכות הזמנה לעמוד, על שיא bytes רינדור שהוזמנו, על קבלות של ה-scheduler, על עמודים שנעכבו, על זמן המתנה, על מספרי הידור ופגיעות cache, על פלט שהושלם, על שיא concurrency של שלב, על latency של תוצאה ראשונה, על זמן חולף כולל, ועל מספר העמודים שעברו הידור כשה-bitmap הראשון הושלם

הקורא מחזיק בבעלות על כל bitmap שאינו nil בתוך Bitmaps

תוצאות המערך שהושלמו נשארות בבעלות הקורא גם אחרי שההזמנות שלהן בעבודה שוחררו, לכן השתמשו ב-RenderLoadedPagesParallelOrdered כאשר קבוצת הפלט המלאה עצמה צריכה להישאר בתוך תקציב ה-scheduler

THPDFParallelRenderPipelineInfo · רשימות תצוגה וייצור הדפסה