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
Introduced with commit 13da5e980e
A compile before pushing would have been great, again.
Having the same name for two variables is something no compiler likes.
evas-map-utils-eo.c:74:8: error: conflicting types for ‘r’
int r, g, b, a, f;
^
evas-map-utils-eo.c:73:19: note: previous declaration of ‘r’ was here
Eina_Rectangle r;
^
evas-map-utils-eo.c:93:31: error: ‘h’ undeclared (first use in this function)
efl_gfx_size_get(o, NULL, &h);
^
evas-map-utils-eo.c:93:31: note: each undeclared identifier is reported only once for each function it appears in
evas-map-utils-eo.c:108:25: error: ‘w’ undeclared (first use in this function)
efl_gfx_size_get(o, &w, &h);
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
In the map examples, the map image UV size was based on the image
source geometry, rather than the image geometry itself.
In the example, this affects how the glass is mirrored. Before this
patch, the reflection is a single line stretched. EFL 1.18 and 1.19
seem to have the same issue, while 1.17 simply fails to show any
reflection. 1.16 fails miserably and the entire window is black.
If the original code was correct, then I believe that map and/or
proxy rendering have been modified in a way that affects the meaning
of those image UV parameters. But this seems like the regression (if
it is one) is in fact quite old.
@fix
Summary:
For people browing through the examples, having the opening statement be
concise and consistent will help them more quickly find what they're
looking for.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Test Plan:
Some of the examples had identical opening statements (e.g. the image
object examples). I've tried to give each a unique description defining
what they are demonstrating, but you may want to doublecheck I got these
correct. Of particular note, to me evas-images5.c looks like just a
fixup to evas-images4.c, so I'm not sure what makes these two distinct.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4861
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Xavi Artigas
Jean-Philippe Andre
Stefan Schmidt
Bryce Harrington