Summary:
When a map property is changed, map draws it.
Before drawing, evas_object_map_update updates map->spans which is data for
actual drawing. But if changed_map is false, then evas_object_map_update does
not update map->spans.
Usually mapped object has following step.
(1) change map data (evas_map_point_coord_set)
(2) render_pre
(3) evas_object_map_update updates map->spans if changed_map is true.
(4) render
(5) render_post -> evas_object_cur_prev -> "map->prev = map->cur"
But if mapped object hides at step(1), then step(3),(4) does not happen. But
step(4) map->prev keeps changed map data. After this point, If same map data
comes, then map does not draw it. Because the new data is same with map->prev.
The issue occurs with following step.
(A) point_coord_set with point A.
(B) (2)(3)(4)(5) works.
(C) point_coord_set with point B. And hide.
(D) (2)(5) wokrs.
(E) point_coord_set with point A. still hide, so none of (2)(3)(4)(5) work.
(F) point_coord_set with point B. And show.
(G) (2)(3)(4)(5) works. BUT step(3) does not update map->spans because
changed_map is false. So you can see image of point A.
The changed_map is changed to false after updating map->spans at step(3).
So usually changed_map is false before deciding changed_map of next render.
In case of not rendering (but render_pre/post) after map data is changed, the
changed_map keeps true. So this patch was suppose to make changed_map
false if changed_map is already ture before _evas_map_calc_map_geometry
decides changed_map which occurs step(1). true changed_map indicates that
you need to draw even though new map data is same with previous map data.
Test Plan: {F3739770}
Reviewers: Hermet, jsuya
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9476
Summary:
the perspective could be handled in the gl backend,
Here map coordinates don't need to get perspective ones but
local coordinates instead as it does same to integer coordinates.
I have no idea origin issues exactly,
but this changed fx, fy values are working correctly in client side.
Reviewers: devilhorns, #committers
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8563
Summary:
map_surface does not redraw in below case.
1) parent and child are smart object and has map.
3) drawing objects.
4) apply new map to child object.
Test Plan: sample code
Reviewers: jpeg, cedric, jypark
Differential Revision: https://phab.enlightenment.org/D4889
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.
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
Since 9b7ac51943 evas map tries to avoid recalculating
stuff when the map parameters have not changed. Unfortunately the
code in elementary_test -to "Flip Page" was badly written. It was
modifying a constant's internal value (after ugly cast). So the
memcmp() and all other checks would return successfully, as the
exact same pointer was being compared to itself.
So, I've fixed the comparison by adding some forgotten parameters
(perspective) but most importantly I fixed the map API usage in the
test case.
This patch introduces the possibility to set the pointer mode and
query other properties like current position per pointer device.
The old API will still works, however it will only act on the default seat.
so smart object bounding box wasnt updated properly in several other
cases. fix those other cases too by dirtying bounding box region.
this continues on from:
f6b3c3156125d77bc1d29f0fd66ab8
this fixes T4017
@fix
It relies a bit on evas legacy APIs and will only work on
evas objects (Efl.Canvas.Object) for now.
The main difference with Evas_Map is that there is no
separate map object, as the functions apply directly to
any canvas object.
For convenience, most functions will automatically populate
the map if there was no previous map info. While this may
be convenient, the object's size changes still need to
be tracked to update the map info.
Those two functions were doing exactly the same thing[1], which
is free an image, so this commit only attempts to simplify the code
a little bit.
[1] Actually image_map_surface_free() might even not have worked
properly with cserve2 sw (calling unload instead of close).
this adds a lock for when walking all the objects to generate render
commands for an async render. this allows even the object tree walk
plus update area caluclation to be moved off into async if every oject
that can change canvas state actually does so correctly. this change
adds all those lock block calls to synchronise with an async object
tree walk.
It's been so long. even SLP is not a valid name anymore.
No idea whether the problem still exist or not.
If it is then it should be reported and fixed.
Summary:
All points in map are double, when try to get point coordinates, there
are issues with rounding.
@fix
Reviewers: Hermet, raster, seoz, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1554
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
since the map_changed is reset right after the map is updated,
it could not decide to redraw the map surface properly.
now map_update() returns the value to redraw the map surface properly.
for more gurantee to update map properly,
we should reset the map changed flag after the map updation is performed.
this will fix a mapbuf bug that map is not updated.
when the map is changed without rendering but it's in the active object list,
the map updation couldn't be happened later that map is rendered. (if the map is not updated at this frame)
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.