Summary:
Here is an additional optmization patch for removing
unnecessary updation of path,
For instance, let's assume this scenario:
If one vg object has 20 path nodes(shapes),
and every single nodes would have 50 path changes.
(like, append_cubic, append_rect, append_xxx ...);
There would 1000 events triggering.
Furthermore, if there are 20 vector objects in one view,
hese events would be triggered 20000 in one frame.
It's insane, actually I could figured out that happens.
and it took a lot of cpu consumption in some vector usages.
efl_gfx_path_commit() is my idea to avoid this.
When path is ready, the path need to get this api call in the last
to make object changed properly.
@feature
Reviewers: #committers, cedric
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7494
Replace fill/stroke renderer preparation of shapes to canvas vg,
These renderer now is triggered by their own instances.
This cairo change part is missing bym cbf70b32f049583fc0bf7542af7d89d4ef5d50c55.
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature
Honestly I can't see why gfx & gfx.path "changed" need a manual
definition, instead of relying on EO. If the API needs to be
internal only, then EO needs to handle internal APIs. In this
case, the event was exposed as a C API but not a EO... why?
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
Rename a few things:
- draw helper -> efl_draw
- Ector_Rop -> Efl.Gfx.Render_Op
- ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops)
- ector_memfill -> draw_memset32 (and invert arg order to match memset)
The main rasterizer file is now draw.h in static_libs/draw
This is a non functional change, simple code refactor.
Coverity reports that 'obj' is written twice with the same value
here., so fix this with a proper call to eo_do_super_ret
NB: Fixes Coverity CID1339786
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This make it part of the object initialization and will prevent the construction
of the object if the needed cairo function are not fund. So if Ector can create
the object, it can display them.
Summary:
Memory leak was caused by using the USE macro. So move the macro before
doing any allocation.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Differential Revision: https://phab.enlightenment.org/D3183
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
From now on, constructors should return a value, usually the object
being worked on, or NULL (if the constructor failed). This can also
be used for implementing singletons, by just always returning the same
object from the constructor.
This is one of the final steps towards stabilizing Eo.
@feature