previously, it had the remaining value issues on blending computation.
The blending color result was in correct.
Signed-Off-By: Vladimir Kuramshin <v.kuramshin@samsung.com>
Summary: It caused crash when clipper is NULL and it makes evas test-suite fail.
Test Plan: Run evas test-suite. (make check)
Reviewers: woohyun, tasn, herdsman, Hermet
Reviewed By: Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2215
Summary:
Fix build failure with old version freetype.
It is caused for supporting colored font.
Reviewers: raster, jpeg, woohyun, Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2200
Summary:
Reinitialize FontConfig. If FontConfig has to be reinitialized
according to changes of system enviroments(ex. Changing font config files), it will be useful.
Reviewers: woohyun, seoz, tasn, cedric, raster
Reviewed By: raster
Subscribers: raster, herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D1962
Summary:
If the clipper is image or has color, it affects to its clipees.
Even if we unset the clipper or change the clipper to another object,
it seems the clipper is not changed.
Test Plan:
Make two clipper objects and one clipee object.
And make clip the clipee according to following example
ex) Clipee object -> inner_clipper -> clipper
evas_object_clip_set(clipee, inner_clipper);
evas_object_clip_set(inner_clipper, clipper);
After checking the result and hide inner_clipper.
evas_object_clip_set(clipee, clipper);
evas_object_hide(inner_clipper);
See the result.
Reviewers: raster, cedric, Hermet, jpeg
Subscribers: woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D2112
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Note: Technically we should not check the color of the fact that
the clipper is a mask and not a simple rect. But because of
real-life performance issues, damage_add was disabled so we're
trying to keep the perf in most cases while being correct in
cases where the clipper is visually important.
Summary:
Change function and variable names to more suitable ones.
Remove FBO_FUNC macros.
Little tidying up from previous commit.
Test Plan: Local Evas GL tests for 1.1, 2.0, and 3.0
Reviewers: jpeg
Subscribers: cedric, mer.kim, mythri, wonsik
Differential Revision: https://phab.enlightenment.org/D2126
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
When the context version between Evas GL and GL backend differs,
we cannot share texture between them.
So, when the driver has support for KHR_gl_texture_2D_image extension,
use EGL image to share between Evas GL and GL backend
Test Plan: Local Evas GL tests for 1.1, 2.0 and 3.0
Reviewers: jpeg
Subscribers: mythri, mer.kim, wonsik, cedric
Differential Revision: https://phab.enlightenment.org/D2115
Summary:
This should enable applications to use GLES 3.0 through evas gl.
Todo: Fix indirect rendering issue occuring because texture objects
cannot be shared between different version of GLES contexts.
Todo: extension pointers need to be updated for GLES 3.0
Reviewers: wonsik, spacegrapher, jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2017
@feature
In some rare cases, a mask would be rendered (from mask_subrender)
into a surface that is NOT an FBO. This would happen because the
previous surface was a "scaled GL image" and its size would
match the required geometry.
That took a while to figure out...
http://thecodinglove.com/post/111546429281/when-i-finally-solve-a-nasty-bug
The previous commit modifies the concept of direct rendering
vs. indirect rendering, so some runtime checks (in debug mode
only) will fail.
This commit introduces two new engine functions:
- gl_get_pixels_pre
- gl_get_pixels_post
The latter will be used in a later patch for optimization.
not changed.
Automatically fallback to indirect rendering on FBO or X11 Pixmap
if the Evas Object Image is not marked as dirty. This should
improve the performance and/or power consumption in those
rare cases where this area of the canvas needs to be redrawn
but the GL content has not changed.
@feature
Use the Khronos version from extension EGL_NV_coverage_sample.
In the extension multisample_coverage version 4 (since 3/7/2013),
there is an explicite note about the name conflict.
The function image_scaled_update() frees() the old scaled image
passed as input if it doesn't match the old dimensions. This commit
will avoid double frees.
Edje may not set the filled flag on an image even if its fill
properties make it fill the whole object. For masking, it can
then be considered as a filled image.
If the image is not "filled", then we can't assume its image
source geometry is the same as its texture geometry.
Note: Implementing a fast path for non-filled images would
require a hell of a lot more work (need to cut the render
into a lot more triangles) for little real-life use.
Call object's function to get the private engine_data (here, the
image object). Thanks Dongyeon for your patch which inspired me to
do that instead of forcing pre_render.
This will currently optimize most of the masks when using the
GL engine[1].
This is a very special case that adds a highly optimized path
for masking in GL. It works by creating a virtual image, containing
a pointer to the original image and a new geometry[2].
Instead of creating a new FBO-based surface (image_map_surface),
we refer to the original image and adjust the mask geometry on
the fly.
KNOWN BUGS:
- masking a map with such a scaled image is now broken.
[1] Right now all masks are simple Evas Object Image, so that means
all cases of masking, except masks of masks, or masks of maps,
will be optimized with this new method.
[2] This virtual image mechanism is still quite hackish and may
be improved (for memory usage, refcounting, etc...)
Those 2 new values are here to avoid using environment variables
that have side effects on the whole application.
I'm actually wondering if we shouldn't just kill off the env
vars altogether. Also, direct override is a terrible option that
should never be used.
Memory optimization can make sense (needs more testing tho).
This is for now just a small experiment. It was based on the experiment made
with OpenMP. I prefered to only use Eina here as we have already all the infrastructure
to do this nicely and simply. As a result I get a 65% speed improved on average for
the involved scaling operation. The secondary CPU is on my laptop running with a load of
75% percent. I don't have right now the time to do power consumption analysis, but I
think it shouldn't be to bad. I am also not throwing more core at this as we are not able
to use the second core at its max already, so additional core may result in a bigger
energy loss without enough gain.
Summary:
Add class and type Evas_3D_Callback like wrapper under smart object
Incapsulate Evas_3D_Callback in Evas_3D_Object
Add virtual function register and unregister in Evas_3D_Object
Add function evas_3d_callback_call
Add callbacks clicked and collision for Evas_3D_Node
@feature
Reviewers: raster, Hermet, cedric
Reviewed By: cedric
Subscribers: artem.popov, cedric
Differential Revision: https://phab.enlightenment.org/D1914
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
this fixes a lot of noise for filled image objects that set fill to
0x0 if objetc is 0x0. this clamps minimum fill at 1x1 and thus keeps
things silent and sensible. also just silently ignore 0x0 filled image
objects. noise is not that useful.
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.
Summary:
See first part https://phab.enlightenment.org/D1811 (backend, gl)
Add get/set for color pick mode at evas_3d_mesh and evas_3d_scene
Add evas_3d_node_color_node_mesh_collect function to collect data at force rendering
Add state flag for scene to avoid useless force rendering in case scene wasn't changed
Add functionality for color pick in evas_3d_scene_pick method
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1956
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
This native surface type is based on the tbm surface used for the tizen platform.
For the software_x11 backend, image data is retrieved from tbm surface
and color format converted appropriately.
This will only work when libtbm.so is present in the system.
@feature
Test Plan: Local tests
Reviewers: raster, cedric, jpeg, Hermet
Subscribers: wonsik, cedric
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
implement native surface set for EVAS_NATIVE_SURFACE_X11 type
on software_x11 backend.
@feature
Test Plan: local tests on PC
Reviewers: jpeg, cedric, raster, Hermet
Subscribers: wonsik, cedric
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Summary:
This native surface type is based on the tbm surface used for the tizen platform.
EGL_TIZEN_image_native_surface EGL extension is used to map
tbm surface to an egl image
@feature
Reviewers: raster, cedric, jpeg
Subscribers: cedric, wonsik
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
A rare case of garbage data would happen if smooth scaling
was called with a mask and 1:1 scaling. Use the proper
render_op to COPY for the first pass.
@fix
Summary:
Added additional texture and framebuffer for rendering meshes to it.
Added function that return OpenGL id additional texture
Added function that return color from target texture by mouse pick coordinates
Added function that render need meshes to target texture
Added engine wrappers for possibility force render to texture
@feature
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1811
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
When getting ellipsis value from evas text object fails,
the most reasonable return value is -1.0.
Currently, evas_object_text_ellipsis_get API with NULL returns 0.0.
It means ellipsis is not off. It must return -1.0 when API fails.
@fix
Comments by Tom: until now, this was inconsistent. With this change, it
now returns -1.0 consistently. Also, fixed commit summary.
Reviewers: woohyun, Hermet, seoz, tasn
Reviewed By: tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1944
Summary:
The order of tranformation changed to scale, orientation, position as
in some cases it can lead to incorrect value for the bounding box.
@fix
Reviewers: cedric, Hermet, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1942
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
During filling evas pick public data by API evas_3d_scene_pick
segfault can occur if mesh was created without texcoords.
See functions - _pick_data_mesh_add, _pick_data_texcoord_update
@fix
Reviewers: cedric, Hermet, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1941
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: When center of bounding sphere was out of frustum and number of intersections between bs and planes of frustum was more then 3, objects disappeared.
@fix
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1938
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Fixes rendering in the following case:
- Object with a map has a mask
- Object is child of smart object which also has a map (eg. transit)
--> Masking did not apply to the children before this patch.
NOTE: This works fine in SW but still didn't work in GL, see the
following commit...
I know. This title does not explain anything. Whatever.
This fixes the following issue:
- Mask a genlist (big mask)
- Each item has an icon masked (small mask)
- Apply a map to the genlist
- Scrolling the genlist
--> The big mask still works but totally screws up the
small icons with masks.
Note: Once again this patch only affects code paths where an
object is a mask.
Yeah, mixing maps and masks of masks in a genlist leads
to tons of amazing bugs :)
This commit removes x,y from the "mask" field in an object,
as they are duplicates of cur->geometry.{x,y} but were not
properly kept in sync.
This patch fixes a situation of:
- A genlist in a map
- Each item has an icon masked
- Scrolling the genlist
--> The masked items would not render properly before this
patch.
Remaining known problem:
- Mask a genlist (big mask)
- Each item has an icon masked (small mask)
- Apply a map to the genlist
- Scrolling the genlist
--> The big mask still works but totally screws up the
small icons with masks.
Note: These changes look scary just before the release
but I would have to backport them to 1.13.x as they
definitely are bug fixes. Also, they only concern
code paths used exclusively by masking.
All those masking bug fixes become harder to explain. But here goes:
- Take a genlist, apply a mask to it (for example put everything
in an elm_layout). Also play with various objects in the genlist.
- Also apply a map to it (for instance, elm_transit zoom).
--> Now some elements will be masked, some others will not,
and some may even not render at all.
This patch restores a mask in the current drawing context, instead
of just unsetting it.
In a situation where an object with mask of mask is in a map
(Yes! It can happen!) the masks would not get properly "multiplied".
Now the problem is that some objects still seem to bypass some
masks... Hmm...
This is a left-over from a previous fix a few weeks ago.
The point of this "if" is just to avoid writing the COW value
if not needed.
For reference:
commit f876cf31f8
Author: Jean-Philippe Andre <jp.andre@samsung.com>
Date: Tue Dec 23 18:57:45 2014 +0900
Evas masking: Fix invalid geometry after mask redraw
Summary:
This is an attempt at fixing:
- T1767: The ultimate evil map & clip bug
Force recalculation and re-propagation of clipper geometry
after or just before a map is applied (only when transiting
between map enabled and map disabled).
I realized that doing clip_unset+clip_set in the E widget
code would fix the issue, but this is not a solution that
makes a lot of sense.
Unfortunately I have no idea about the side effects of this
patch, especially in terms of performance.
Fixes T1767 and maybe T1630.
Test Plan:
Open PackageKit popup in E, check the animations
and that clipping works fine both during, before and after
the animations.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric, Hermet
Maniphest Tasks: T1767
Differential Revision: https://phab.enlightenment.org/D1897
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
While invesigating some clip & map issues, I found some very
strange piece of code:
{
tmp = a;
a = c;
a = tmp;
}
This actually comes from a very old code refactoring where a
line in-between was removed:
tobj = obj->cur.map_parent;
obj->cur.map_parent = obj->cur.clipper->cur.map_parent;
- evas_object_clip_recalc(obj);
obj->cur.map_parent = tobj;
Adding this line back there doesn't seem to do anything anyways.
So, let's just remove useless code.
For the record (legacy evas):
commit e1f6f3c5f239dfd95a307949acd5f98831c0c3c0
Date: Fri Aug 17 06:16:04 2012 +0000
evas/render - code refactoring.
SVN revision: 75351
Some complex examples of masking with mapped smart objects
would fail miserably, rendering the object without any mask,
and/or showing the mask itself somewhere in white color...
The memory usage graph was going up and to the right!
I was told this is always a good thing!
... maybe not this time :)
Hopefully I didn't forget a case. An intense session of
genlist scrolling with masks all over the place and masks
of masks didn't show any glitch, crash or memory leak.
The main difference between 1.12 and 1.13 memory foot print is actually
related to this two pointer to mask. I am wondering if there is not an
issue here also has we do have a duplicated pointer. We have prev_mask
and mask in both cur and prev state of an Evas_Object, but only mask
and prev_mask from the cur state seems to be accessed.
If we can remove two pointers from those state, we should have a decent
win in expedite benchmark. Hopefully 300KB to win there (Close to half
the additional cost in memory).
The flag should be set on the mask itself.
Checking for (x,y) being inside the mask can be an expensive operation,
so further optimization will be required.
Summary:
There was no conversion to the double quotation mark in the evas_textblock_text_utf8_to_markup function.
The price of the text coming out to API and text coming out to Textblock was different as a result.
As a result, Two text lengths came out differently.
So, I added the exceptional treatment part in the evas_textblock_text_utf8_to_markup function.
@fix
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1853
Summary:
There will be several methods to set orientation in edc, so we have decided to make one big vector,
the main reason is that we use quaternion by default, but look_at, for example, is given as 6 coordinates.
Reviewers: Hermet, cedric, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1693
Well... actually this is not exactly a fix.
It just restores the previous behaviour, and allows AA to
work. As in, it won't draw ugly black lines but properly
blend to transparent.
But there is still a problem:
The image map render function changes the alpha flag on the source
image if AA is enabled or if the map has an alpha color. This is
actually wrong as images forcefully set to not have any alpha
(with evas_object_image_alpha_set(0)) will then not be opaque
anymore.
Right now I can't think of a solution (also I don't quite follow
the entire pipeline in evas map...). Changing the flag will
make some opaque areas transparent. Not changing the flag will
produce ugly artifacts where AA blending should happen. Fix one
bug and the other appears, and vice versa.
This can be tested with the example evas-map-aa and adding an
alpha channel to cube1.png (with gimp for instance) but manually
setting alpha to 0 in the code. Weird stuff will happen (try
playing with the map and pressing I to switch to/from image mode).
The selected op func was not performing the correct operation,
thus producing rendering artifacts. These functions should not
be used anywhere except in case of masking... which was not an
available option earlier.
It was doing (wrong):
dst = interp(mask, src, dst)
Instead of (correct):
dst = dst + (1 - mask) * src
NOTE:
This commit also disables MMX, SSE3 & NEON implementations of
pixel_mask blend operations, since they are also broken.
In case the clipper is a mask object, we should use precise
event masking. By default precise_is_inside is not enabled
because it is expensive, but it should probably be set by
the application when they use masks as clippers.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
This implements supports for masking inside evas_render, which
means:
- Render the mask itself into a surface (ALPHA if possible)
- Pass this mask surface to the draw context
- Apply mask recursively in case a masked object is contained
by another masked object.
@feature
Work done by Jaeun Choi, rebased & squashed by jpeg.
This commit introduces changes to the low-level draw functions
of the SW engine considering the existence of an alpha mask image.
Features:
- Font masking (TEXT, TEXTBLOCK),
- Rectangle masking,
- Image masking (all image scaling functions should be handled).
The mask image itself is not yet set in the draw context (see
following commits).
@feature
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
So I've discovered some weird output values after drawing
some text. The destination alpha would become 0xFE even
when the back buffer had a background with 0xFF alpha.
Example:
Dest is 0xff00ff00 (green).
Color is 0xffffffff (white).
Current font alpha is 170 (0xaa).
--> Output was 0xFEaaFEaa instead of 0xFFaaFFaa.
This is because of some slightly invalid calculation
when doing the font masking (mtab[v] = 0x55 above).
Indeed, MUL_256 takes alpha values in the range [1-256]
and not [0-256] as was assumed.
There was a problem when checking whether the current surface
is compatible with direct rendering. In case of client-side
rotation (it's a flag set on the surface by the app), a surface
can be directly rendered even if the rotation is not 0.
But, before this patch, it was assumed that the surface was
current. Which doesn't make sense because make_current is
called by the pixel callback, from the application, and this
happens *after* we check for direct rendering.
As a consequence, it was not possible to mix directly rendered
surfaces with FBO-based ones, and use client-side rotation.
This patch should solve that issue.
This should ensure that the difference between the original
pixel value and the rle4 encoded one is <= 8.
The previous fix was a bit stupid as it was not taking into
account the conversion a4 to a8 (which is a8 = (a4 << 4) | a4).
Summary:
Move check visibility of node from evas_3d_node to evas_3d_camera
Move functionality (normalize, check distance, calculate frustum)
in evas_3d_utils.h (we are planing use evas_is_sphere_in_frustum in evas_gl_3d.c -
don't render mesh if it non visible)
Add possibility check frustum by box, aabb, central point
Refactor example frustum culling
@feature
Reviewers: Hermet, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1420
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Cedric BAIL
ChunEon Park
Youngbok Shin
Carsten Haitzler
Jihoon Kim
Bryce Harrington
Dmytro Dadyka
Dongyeon Kim
mythri.venugopal
Jean-Philippe Andre
se.osadchy
Daniel Juyung Seo
Tom Hacohen
Boris Faure
Oleksandr Shcherbina
Yomi
kabeer khan
Dmytro Dadyka
Bogdan Devichev
Amitesh Singh
Jean-Philippe Andre
Stefan Schmidt
ChunEon Park
Daniel Zaoui
Chris Michael
Jae Yong Hwang
perepelits.m
Jaeun Choi
Andy Williams
Srivardhan Hebbar
Mun, Gwan-gyeong
Gwanglim Lee