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
This patch adds support for map with more than 4 points.
However, we only support points with multiples of 4.
This also adds efl_gfx_map_point_count_set/get APIs to
set number of points.
@feature
The COW object may have not been created if the object could
not be created. Example: a window failed to open because the
engine could not create a surface.
I've done this by translating "Flip Page" to this new set of
EO APIs. In particular, absolute coordinates need to be used
in some calls, and the map needs to be calculated between
get and set operations.
This required an adjustment of the raw_coord API as the flip_page
code does some math after reading and then writing to the map.
Same for color. Those two properties now act like commands (ie.
like the other gfx map functions).
This also introduces a duplicate set of APIs to handle absolute
coordinates. Other solutions included:
- Use an enum to specify the type of coordinates (but then the
unit of cx,cy varies between non-unit relative position and
pixel position. Also this adds an extra argument to all those
function calls.
- Pass a special value (an empty eo object) as the argument for
pivot. Same remark about the unit as above. This way was
deemed too confusing because of the weird object.
Those two options have been discarded after asking the opinion
of a few developers I could reach.
@feature
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
Manual points population will eventually be useless as the
map API will become more like a transformation API, where
the current object geometry doesn't matter as much as which
transformation is applied to it.
Jean-Philippe Andre
Thiep Ha