Summary:
evas_gl_common_image_content_hint_set makes RGBA_Image NULL if content hint
is EVAS_IMAGE_CONTENT_HINT_DYNAMIC with 'sec_tbm_surface' and 'egl_tbm_ext'.
efl_file_save(_efl_canvas_image_internal_efl_file_save_save) does not work
in this case because ENFN->image_data_direct_get returns FALSE.
This patch makes ENFN->image_data_direct_get work but you need to free its
returned data after using it.
Reviewers: Hermet, jsuya
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8516
evas map has used integer coodinate system since it's born,
since object's transition is jiggled, not perfectly smooth.
It's obvious because Positioning must be stepping with integer units
without any subpixel rendering.
Currently, this patch is a sort of preparatory to improve this,
only valid for high-quality evas map (smooth + anti-aliasing)
This implementation uses Ector_Buffer to generate mask image from vg container,
and pass it to Ector engine. Ector renderer could blend this image as a mask.
Yet only vg container works as a mask, we could extend shape to support masking later.
Still vector gl drawing is not completed, We use software ector buffer to draw on it.
This is on progessing.
so gcc now is being very picky about types. since we'r ereallyjast
throwing void *'s around for pointers to funcs and looking them up by
hand - use void *'s to avoid warnings.
Summary:
Current preloading is too buggy since it's on thread-based.
This is a fundamental improvement to fix a bug.
The critical issue here is,
When preloading img object suddenly cancel its preloading,
the object possibly cannot render image next then because
renderer doesn't have any idea when async cancelling is
finished. Renderer just tries to render regardless of
image loading status, and this could occur no-texture(in gl case)
image object.
So, here improvement is, adding a notification for async cancelled
so that putting img objects to redraw images properly after their preloading is
cancelled.
The best scenario to reproduce this bug is this one.
Evas_Object *img2 = evas_object_image_filled_add(evas);
evas_object_image_file_set(img2, "test.jpg", NULL);
evas_object_image_preload(img2, EINA_FALSE);
evas_object_resize(img2, 200, 200);
evas_object_show(img2);
Evas_Object *img = evas_object_image_filled_add(evas);
evas_object_image_file_set(img, "test.jpg", NULL);
evas_object_image_preload(img, EINA_FALSE);
evas_object_move(img, 200, 200);
evas_object_resize(img, 200, 200);
evas_object_show(img);
evas_object_image_preload(img2, EINA_TRUE);
If you run this on gl backend, occasionally happens rendering fail.
Yet there other bugs on preloading feature....
@fix
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6919
Summary:
Adding cache targets in other modules are inproper.
This can't be managed by cache module inside.
One representive scenario is,
when preload cancel is triggered, preload canceling sequence
can't be performed properly because cache targets implicitly were
increased by backend modules.
And then, Cache itself couldn't get notified it.
see this condition.
if ((!ie->targets) && (ie->preload) && (!ie->flags.pending))
in _evas_cache_image_entry_preload_remove()
Consequently, I move preloaded callbacks to sync with adding cache targets,
not to add by backed engines themselves.
This will bring Cache to manage cache targets properly.
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6912
Summary:
That redundant code just made code complex.
This is one of intermediate patches for preload
Reviewers: raster, #committers
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6907
Summary:
"plane" exception value is already filtered at line 1791.
execution cannot reach this statement.
Reviewers: cedric, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5973
Summary:
Increasing offset as 2 for next map points is wrong.
If evas tries to draw for wrong combination of map points,
it can cause wrong results. Actually, every drawing code for
map points use and increase offset as 4.
@fix
Test Plan:
A test case for textpach is modified for testing this issue.
1. Run elementary_test with sync render mode.
ex) ECORE_EVAS_FORCE_SYNC_RENDER=1 elementary_test
2. Open textpath test.
3. Set a short text by clicking newly added check box.
4. (It will show another issues... So,) change slice number to update textpath properly.
5. See some noises at top-left side of text.
It is drawn from the two of end map points to the two of empty(not used) map points.
Reviewers: raster, cedric, jpeg, jypark
Differential Revision: https://phab.enlightenment.org/D5833
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
For SW engine we need to verify that OSMesa is present. The patch
fb048e7312 broke the logic.
Tested by temporarily removing OSMesa from my system.
Fixes T6617 (again)
osmesa needs llvm. llvm apparently just by dlopening or linking to the
lib (libLLVM...) gets you 3.5mb of dirty pages just in this lib. that's
a whole lib entirely dirty pages. odd and horrible. in fact once i
stoppd dlopening OSMesa all the time on engine init (and only when gl
is needed)... the amount of dirty pages went from 17208 to 8860.
that's a whopping drop of 8mb! 8mb saved! in fact just dlopening
osmesa and doing the other gl init stuff led to more anonymuse
mappings with dirty pages. 2 of them (2072k and 2076k) which baffled
me as that didn't seem like heap or efl's own data. these disappeared
along with libLLVM-5.0.so (3520k + 60k dirty pages). we stopped
linking/loading libedit (12k dirty), libglapi (20k dirty),
libLLVM-5.0 (3580k dirty), libncursesw (72k dirty),
libOSMesa.so (260k dirty), libtinfo (20k dirty). ... or at least
stopped until absolutely needed. total 17208k of dirty pages went down
to 8860.
my test case was just launching terminology (and doing nothing with it).
@fix memory bloating
Summary:
The default backend overrides this operation depending on the fill color
but the cairo backend dosen't hence cairo will always use bled mode while drwaing the vector.
Reviewers: jpeg
Subscribers: vtorri, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5724
In most engines which inherit from software_generic, they do not
implement the outbuf_free_region_for_update function. Most engines
have it as an unused function. If we simply add a check here, then we
can reduce the need for having useless function in multiple engines.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
Since the EO APIs are defined as weak symbols, invalid definitions of
EAPI lead to runtime crashes on non-public APIs. This is a fix following
a series of changes wrt. EAPI definitions.
This has been a stub for a long time, but now we have a native_set, so
we should have a native_get too.
This is required for hw plane usage on the software engine.
Functions to assign a plane for a native surface, and release a plane
that's been assigned to a native surface.
These are empty for now as they'll need to be overridden in any backend
that can handle planes.
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).
Alright, so this is a massive patch that is the result of
trying to get rid of unused or poorly implemented classes in
ector. Originally ector was meant to support VG but extend to
things like filters as well. At the moment, ector's design
makes it quite hard to plug in the filters.
For now I think it's easier to implement the GL support for
the filters directly in the engine, where I hope to interfere
as little as possible.
This massive patch keeps only the required minimum to support
a versatile gl buffer that can be mapped, drawn or rendered to (FBO).
It's extremely inefficient as it relies on glReadPixels and lots
of texture uploads, as well as conversions between ARGB and Alpha.
Another type of GL buffer is a wrap around an existing GL image,
but that one is read-only (map or draw: no write map, no FBO).
No, all the filters run fine, and the high-level implementation
(evas_filters.c) does not need to know whether the underlying engine
is SW or GL. One problem though appears with the blending or blurring
of some Alpha buffers, the colors are wrong.
This patch removes more lines than it adds so it must be good ;)
Shinwoo Kim
Hermet Park
Carsten Haitzler
Chris Michael
Bowon Ryu
Cedric BAIL
Youngbok Shin
subhransu mohanty
Jean-Philippe Andre
Derek Foreman
Thiep Ha