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.
There was a big trouble that vg cache didn't free cached data properly.
Plus, there was a unnecessary copy of vg tree data.
This revised version is a improvement of our evas vg cache
in stable and optmization.
Summary:
GLPIPES is proved to use since it's been used for many years as the default.
On the other hand, single-line routine hans't, acutally it's not maintained properly.
Even this single-line routine doesn't compileable right moment.
This patch is one refactoring to clean up code that's not valuable to maintain.
Reviewers: #committers, raster, cedric, ManMower
Reviewed By: #committers, ManMower
Subscribers: ManMower, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7328
Summary:
When we meets a new shader program in shape_context_push(),
it loads a shader binary, if it is necessary, create a new program for the shader.
In this step, the current program state could changed to this new one.
But still our gl context by shader_flush() could keep the previous program for next shader flush.
But it doens't know current program was changed by dropping by.
Here is a simple scenario:
1. evas_gl_common_context_image_push():
This image requires Program A. it calls evas_gl_common_context_push() internally.
then shader_array_flush() instantly.
It stores the current context including shader program(Program A)
2. evas_gl_common_context_xxx_push():
call evas_gl_common_shader_program_get().
xxx draws first time, it loads a new shader program.
Now this changed the current program to a new instant one.
...
3. shader_array_flush():
draw image which requires Prorgam A (No.1).
Unfortunately, stored context is same to this.
So, it skips some gl context setting including shader program.
@fix
Reviewers: #committers
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7309
Theoretically this shouldn't be necessary, but it may be possible for
a backend to give us a visual with translucency even if we didn't ask
for one.
also better comments.
Differential Revision: https://phab.enlightenment.org/D7248
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
The module name and installation directory where previously picked from
the last engine being processed instead of being unique to the VNC Server
module. This patch ensure that we do not write over another engine and
break everything when the VNC Server support is turned on.
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7290
warnings now are being super picky with:
../src/modules/evas/engines/software_x11/evas_xlib_buffer.c: In
function ‘evas_software_xlib_x_output_buffer_new’:
../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:306:56:
warning: cast between incompatible function types from ‘void
(*)(Display *, XErrorEvent *)’ {aka ‘void (*)(struct _XDisplay *,
struct <anonymous> *)’} to ‘int (*)(Display *, XErrorEvent *)’ {aka
‘int (*)(struct _XDisplay *, struct <anonymous> *)’}
[-Wcast-function-type]
ph = XSetErrorHandler((XErrorHandler)
can we really match a struct <anonymous> somehow? i don't think so...
so... void to the rescue.
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.
so getting context at least on some dviers is expensive. it may really
impact cpu usage a lot (in this cate getpid() was being called by the
nouveau drivers and that can be expensive. it is on ARM as it's a full
syscall and 1-2% of cpu time was just getting pid all the time thanks
to this...
@opt
This uses the meson/ninja depfile functionality + eolian to make
sure proper dependencies between generated files and .eo files
are managed, to ensure consistent re-generation of all generated
files that are affected upon .eo file modification.
For custom rules with multiple outputs, Ninja currently does not
support depfiles. Therefore, split those into two custom rules
so that the depfiles functionality can be enabled. While this
is ugly and slows down the process a little by having to invoke
Eolian twice instead of once, it has to be done and it's still
better than what we had in Autotools anyway.
Differential revision: D7187
Fixes T6700.
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
When we reset of texture for a valid object,
this object cache size become -1 x -1 with null texture.
Later, we reset a new texture of the object,
Its texture size could be -1 x -1.
That brings to incorrect result drawing.
Can't see any points of using cache size there.
This bug was introduced by 9e01cf2698
@fix
Reviewers: #committers, raster
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7077
Summary:
We're doing this all wrong.
We've asking for "at least 1 bit" of A, R, G, B color depth.
ARGB2101010 fits that nicely, so mesa on radeon gives it to us.
This only fixes the drop shadows though, it's entirely possible that
a fullscreen window without alpha would get ARGB2101010 instead of
XRGB8888, so this code probably needs a rethink for multiple engines.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7022
It is now similar to how other modules are handled.
Differential Revision: https://phab.enlightenment.org/D7016
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
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:
While debugging a problem,
found a hole that upload texture twice unnecessary.
Here is the scenario.
Set up two objects with same image resource plus both preloading - obj1, obj2;
After image preloading,
_evas_cache_image_async_end() will be triggered.
=> ie->flags.update_data = true;
then first obj1 is gonna drawing,
Since it doesn't have any texture uploaded yet,
it will create a texture and upload texture data as well.
along with below sequence.
=> else if (!im->tex && !ie->load_error)
After it, second obj2 is gonna drawing.
But actually its texture is already readied after obj1,
it doesn't need to upload texture agin.
But still ie->flag.update_data == true, it will do dumbly.
Reviewers: #committers, devilhorns, raster
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6902
Summary:
this is more or less a dead project, having not been actively developed
in over 2 years and instead forcing people to expend more time and energy
to keep it compiling across refactors
fix T7227
Reviewers: stefan_schmidt, Hermet, ManMower, devilhorns
Reviewed By: Hermet, devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7227
Differential Revision: https://phab.enlightenment.org/D6878
Marcel Hollerbach
Hermet Park
Chris Michael
Derek Foreman
Carsten Haitzler
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz