[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Implementation testing\n\nReview the following information to test graphics implementations.\n\nFor benchmarking, use the following flow by phase:\n\n- *Specification.* When initially specifying the device (such as when using immature drivers), use predefined (fixed) clocks and workloads to measure frames per second (fps) rendered. This gives a clear view of hardware capabilities.\n- *Development.* As drivers mature, use a fixed set of user actions to measure the number of visible stutters (janks) in animations.\n- *Production.* When a device is ready for comparison against competitors, increase the workload until stutters increase. Determine if the current clock settings can keep up with the load. This can help you identify where to slow the clocks and reduce power use.\n\nFor help deriving device capabilities during the specification phase, use the\nFlatland tool at `platform/frameworks/native/cmds/flatland/`.\nFlatland relies on fixed clocks and shows the throughput achievable with\ncomposition-based workloads. It uses gralloc buffers to simulate multiple window\nscenarios, filling in the window with GL then measuring the compositing.\n| **Note:** Flatland uses the synchronization framework to measure time, so your implementation must support the synchronization framework."]]