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>
Jean-Philippe Andre
Bryce Harrington