Renamed internal interfaces.
We need both blender & compositor interfaces.
Renamed SwCompositor -> SwBlender which is for pixel joining methods.
Added (SwCompositor, Compositor) which is designed for compositing images.
Introduce RendererMethod::renderRegion() to return acutal drawing region info.
That is used by scene composition to composite actual partial drawing region
for better performance.
@Issues: 173
There is 1 pixel misaligned issue observed.
Found out transform() increases 0.5 pt always.
This transform() logic was broken by this change - e00f948705
and now recorvered to origin.
* sw_engine raster: code refactoring & optimize code.
1. move the computation out of rolling if possible.
2. renamed internal variables & function prototypes.
Add RawLoader class that loads and display raw images,
and adds a Rasterizer for image data.
Image data can be loaded via picture.
Loaded image supports Composition, Transformation and Alpha blending.
New API
Result load(uint32_t* data, uint32_t width, uint32_t height, bool isCopy) noexcept;
we introduced shared memory pool for avoiding reallocate memory
while it process the stroke outlines, It experimentally increase
the outline data if we use the allocated memory for multiples shape strokes,
we don't need to alloc/free memory during the process.
This shared outline memory is allocated for threads count
so that we don't interrupt memory access during the tasks.
@Issues: 75
It missed to update shape data if visilibity is changed from false to true by alpha.
Also, it needs to update engine shape data for every requests.
There scenario can be allowed,
1. update shape
2. change shape property
3. update shape
4. draw
previously engine could skip step 3, its result was not properly expected.
@fix #84
common sw_engine: Implement ClipPath feature
Paint object can composite by using composite API.
ClipPath composite is clipping by path unit of paint.
The following cases are supported.
Shape->composite(Shape);
Scene->composite(Shape);
Picture->composite(Shape);
Add enum
enum CompMethod { None = 0, ClipPath };
Add APIs
Result composite(std::unique_ptr<Paint> comp, CompMethod method) const noexcept;
* Example: Added testClipPath
we should avoid code insertion during file dependencies,
such as #include "xxx.h" which has implementations.
This could increase binary size, we can avoid it as possible.
Current patch improves binary size like this:
From: file(2059008) = text(120360) data(8096) bss(80) dec(128536)
To : file(1921832) = text(118429) data(7872) bss(56) dec(126357)
More additional patches will come in to optmize binary size.
Now, we have 2 points for asynchronous behaviors.
1. update shapes:
Each shape update will be performed by async when you push shape to canvas.
Meaning, if you have time gap between update and rendering in process main-loop,
you can have a benefit by this.
2. rasterization by canvas:
Canvas.draw() will be performed asynchnously until you call canvas.sync();
Meaing, if you can trigger tvg rendering eariler than composition time.
You can have a benefit by this.
If these 1, 2 points might not work for your program,
You can just toggle off async by setting threads number zero at initialization.
Or if you could apply either point of them for your program,
It might be good for performance.
But the best approach is to make both async properly.
Though this might need to fine-grained tuning integration between your program & tvg,
You could achieve the best peformance by parallelzing tasks as possible without any jobs delaying.
Change-Id: I04f9a61ebb426fd897624f5b24c83841737e6b5b
Actually Dali rendering system requires abgr8888.
We could add more colorspaces if it's necessary.
Change-Id: Ia42a6575d1313629e55efc3077e302992c47b6c0
We can use RGBA colorspace rather ARGB for pixel data.
This would be better for many rendering system,
since it's more widely preferred than ARGB including opengl.
Change-Id: Ibbfe6a511d77bf0ef30ce261995467c11164d306
we can't control any threads count that could drop the performance.
remove async() and will come back with fine-tuned threading-pool.
Change-Id: I17c39792234acfce6db334abc0ce12da23978a9a
Some user have no idea of premultiplied alpha concept,
We suggest more user-friendly interfaces so that they don't confuse it.
Now, this pre-multipying is acommplished by backend engines.
Change-Id: Ifd84d56361cb56a8b98240bbd16690accf370bad
previous fast track logic is useless,
it actually doesn't helpful for performance, just increase the code complexity.
Change-Id: Ib6ad204edfb241d74c41413dfec7ab42fb02af81
if the transform scale factor for x/y is not identical,
it keeps its both xy scale factor then apply them
for stroking calculation.
Change-Id: I519dfce3ce7b4a12c13da1801d6a00e139e7400f
Basically, stroke width size is linear,
engine couldn't apply scale factor from the matrix which contains 2 dimensional values.
Thus, we can apply it if the scale factor of x/y is identical.
Otherwise, we should transform every stroke points in the stroking process.
That scenario can be improved with another patch.
Change-Id: I070dcf29d2e42f21e182bdf4239781464158ef73
sw_engine simulates floating point by integer bit shifting,
it loses the accuracy while converting the number data.
This occurs the inacculated curve points result if it scales up very large size.
So we transform points before converting data in order to avoid losing the numbers less decimal point.
Change-Id: I0172e83f06b1a19143a2f65f667dc193e9a4396a
avx is the cutting edge method for intel & amd cpus simd instruction.
We are going to support this feature for the desktop environment (instead of sse)
You can turn on this with configuration something like this:
$meson . build -Dvectors=avx
Current patch supports only for raster solid color
Change-Id: I068ba30a1f63d480415e2762f8021fc8d6d28a39
we don't need to apply anti-aliasing if stroke is there.
here turns off anti-alias if stroke width is more than 2.
magic number 2 is experimentally confirmed.
Change-Id: I09031dc2a0a84f31c5904651ed1e62004645ba9a
if the rectangle is not transformed, we don't need to use rle method.
we can directly raster pixels onto the bounding box.
Change-Id: I4e8b57149c0bcd78124d09388bf5115093a43bee
there are unnecessary partial spans generated in orthogonal rectangle.
we can merge those partial spans to others if they are on the same scanline...
Change-Id: I35a437a4f2eec106bd50f46f0390c652e617311d
memset() is more than 10x faster than manual loop.
Thus we replace it to manipulate buffer pixels.
Change-Id: If0f255578f7d49ff6704c4f15e2eefe435cc3c15
We prefer to build up a tiny compact engine at memory rather than compatibility,
this engine is not considerd for end-users but designed for middle-level framework
and some low-level users.
Thus, we won't consider 64bits data size,
use explicit 32 bits data until coming next upgrade...
Change-Id: I0704d5f1e0eb909cccc10922bc5972e115fbbcc0
Each scene could conserve its own transformation,
the origin could be the parent Paint (if they were beloned to)
Thus, you can compose the multi-tranformed scene group which
simultenoulsly working in own spaces.
See testTransform and testSceneTransform, how they work.
Change-Id: I51deb4d66f8fcd024f8dc7a1e1af57c398a9d7fe
Paint supports translate, rotate, scale functions for transformation
The origin of these transformation is center of the paint,
thus you have to consider the center-aligned vertices if you'd like to use
these transformation functions.
This policy has been considered for scene transformation.
Change-Id: I78b63d7965faec0ec5b9a98a7776993744534b54
Come to think of it, this optimized method is not so useful,
it could just bring the user misunderstanding and
not to efficient as I expected in the most cases.
So, changed policy for transformation behaviors.
it keeps the properties as others but leaves it to the backend implementation.
Plus, this change contains the correct RenderUpdateFlag.
You can refer the flag in the backend to figure out which kinds of properites has been updated
Change-Id: Ibe0494712598a8161950b9ae2e22ac45bed1c47b
