 |
Flutter Engine
The Flutter Engine
|
Loading...
Searching...
No Matches
|
Flutter Engine
The Flutter Engine
|
#include "include/core/SkMatrix.h"#include "include/core/SkRect.h"#include "include/core/SkString.h"#include "src/gpu/ganesh/GrGpuResource.h"#include "src/gpu/ganesh/GrMemoryPool.h"#include "src/gpu/ganesh/GrTracing.h"#include "src/gpu/ganesh/GrXferProcessor.h"#include <atomic>#include <new>Go to the source code of this file.
Classes | |
| class | GrOp |
| class | GrOp::ChainRange< OpSubclass > |
Macros | |
| #define | GR_OP_SPEW 0 |
| #define | GrOP_SPEW(code) |
| #define | GrOP_INFO(...) |
| #define | GR_FLUSH_TIME_OP_SPEW 0 |
| #define | DEFINE_OP_CLASS_ID |
| #define DEFINE_OP_CLASS_ID |
| #define GR_OP_SPEW 0 |
GrOp is the base class for all Ganesh deferred GPU operations. To facilitate reordering and to minimize draw calls, Ganesh does not generate geometry inline with draw calls. Instead, it captures the arguments to the draw and then generates the geometry when flushing. This gives GrOp subclasses complete freedom to decide how/when to combine in order to produce fewer draw calls and minimize state changes.
Ops of the same subclass may be merged or chained using combineIfPossible. When two ops merge, one takes on the union of the data and the other is left empty. The merged op becomes responsible for drawing the data from both the original ops. When ops are chained each op maintains its own data but they are linked in a list and the head op becomes responsible for executing the work for the chain.
It is required that chainability is transitive. Moreover, if op A is able to merge with B then it must be the case that any op that can chain with A will either merge or chain with any op that can chain to B.
The bounds of the op must contain all the vertices in device space irrespective of the clip. The bounds are used in determining which clip elements must be applied and thus the bounds cannot in turn depend upon the clip.
1.9.8