Summary:
On the sw engine, an im could be changed and removed by evas_cache_image_size_set.
In this case, there is no chance to free its resource and ends up in memory leak.
Reviewers: Hermet, raster, jsuya, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10334
if your platform is picky enough it won't want to leave unresolved
symbols (which wshould be resovled at runtime from the host lib) so we
need to link these modules to evas. the problem is due to the
complicated build of some modules being static and some shared, evas
is declared with evas_goal and this has to be declared after static
modules are declared but since i was declaring static and shared at
the same time from a table this breaks. so i have to move all the
static and shared module stuff into evas_goal into 2 phases. one phase
for the static and one for the shared after evas is delcared so evas
as a target exists to link to.
so the evas modules able to be static or not was a bit pointless as it
could inline all evas modules (or none) not just the most common or
not, but ecore evas modules were still modules, so it really wasn't
being useful.
image loaders ans savers omn the other hand were *ALL* being
statically built in without exception. this was kind of a regression
in the build system in the move to meson. some were static due to
micro optimizations and performance inlining the most common to save a
little extra loading + linking + page fragmentation for loaders you
are likely to need in most cases as well as save the drity pages from
linking in their dependencies (libgif, libtiff, libwebp and all their
dependencies too etc. etc.). this now brings back the ability to
decide which are static and which are shared modules (not exposed to
the user as options for meson - fixed in meson.build files which i
think is good enough given the purpose of this).
evas-modules affects evas engine modules if they are static or shared,
but ecore evas modules are still modules... so all in all this doesnt
help much as it still requires modules to be separate from the shared
libs, thus disallowing for statically linking efl into an app anyway
etc. etc. etc. ... so less options to deal with, less complexity.
better.
Summary:
Initial version implementing grayscale filter in pure GL.
This patch needs a logt of love as 5bce712 did.
Grasyscale formula:
https://www.tutorialspoint.com/dip/grayscale_to_rgb_conversion.htm
Test Plan:
1. Create filter_example with following .
efl_gfx_filter_program_set(image, "grayscale ()", "grayscale");
2. Run.
ELM_ACCEL=gl ./filter_example
Reviewers: Hermet, jsuya
Subscribers: ali.alzyod, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9858
the default still is gl-es as documented. you need to explicitly turn
on full opengl to get gl support on osx because thats all the engine
does. document this exception for osx (having gl magically being full
on osx and gle-es elsewhere is another option but then we need
different os specific defaults for this which is kind of bad in other
ways).
If we check reference validation, the rest of other usage
should keep the reference check as well.
Remove it since gl prorgram must be valid always here
to shutdown the static analyzer reporting this suspicous logic.
Summary:
Crash depending on LOCALE when using strtod.
So change to eina_convert_strtod_c which is made to prevent strtod problem.
Test Plan: N/A
Reviewers: Hermet, smohanty, kimcinoo
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9988
For reducing maintainability burden,
We drop supporting cairo backend.
The default backend is to software implementation from now.
It's well maintained so far and works good.x
fixes ylee's xpm loading issue... it really is just that xpm's didn't
load if you preload/load from a thread... because it wass the only
loader that claimed it couldnt be threaded... which it can be.
@fix
so we USED to... if buffer age changed between frames, force a full
redraw and add that to the pipeline... somehow someone removed that.
this brings that back as it's really needed to deal with updating
correctly.
@fix
Accidentally commit "382c580 evas: add support for .9.png file to PNG loader."
adding the 9 patch feature with small code refactoring missed a line calling
eina_file_map_all taking EINA_FILE_SEQUENTIAL for data decoding.
You can see the previous change adding the line from the following commit.
e60baa0 evas: change mapping policy to be less agressive into loading file
in memory.
This is a response to the request of @cedric on D9580
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9614
Summary:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
Summary:
The evas_image_load_file_data_png had called png_set_tRNS_to_alpha
from following commit.
6988a38 evas: fix png loader to actually produce lower resolution
content when asked.
You could refer to following information regarding png_set_tRNS_to_alpha
which is available on page http://www.libpng.org/pub/png/libpng-manual.txt
The following code transforms grayscale images of less than 8 to 8 bits,
changes paletted images to RGB, and adds a full alpha channel if there is
transparency information in a tRNS chunk. This is most useful on
grayscale images with bit depths of 2 or 4 or if there is a multiple-image
viewing application that wishes to treat all images in the same way.
if (color_type == PNG_COLOR_TYPE_PALETTE)
png_set_palette_to_rgb(png_ptr);
if (png_get_valid(png_ptr, info_ptr,
PNG_INFO_tRNS)) png_set_tRNS_to_alpha(png_ptr);
if (color_type == PNG_COLOR_TYPE_GRAY &&
bit_depth < 8) png_set_expand_gray_1_2_4_to_8(png_ptr)
Accidentally commit "382c580 evas: add support for .9.png file to PNG loader."
adding a new feature with small code refactoring missed the line calling
png_set_tRNS_to_alpha.
So we got a rendering issue. It made around 75% size white rectangle
using a grayscale and transparent image. I'd like to attach the image
which has following type information for test purpose.
$ identify -verbose ./grayscale_transparent.png | grep type -i
Mime type: image/png
Type: Bilevel
png:IHDR.color-type-orig: 0
png:IHDR.color_type: 0 (Grayscale)
Test Plan:
This is the sample image file grayscale_transparent.png
{F3748665}
Reviewers: cedric, Hermet, jsuya
Reviewed By: Hermet
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9580
do it once and remember the result from the first one. drops overhead
for sure by a chunk i actually could see in perf reports like about 1-2%
of cpu...
tracking some seemingly not so good asan hits on the eina file where
we're accessing an eina file already closed... so be extra paranoid
about it and set things to null after free/close...
add a wrapper function for glFramebufferTexture.
some bugs were fixed.
I tested on Ubuntu 14.04(x64) and nVidia 375 driver with VK-GL-CTS
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D4831
The eet_data_read() api creates the structure by referencing the wwt data structure
and reading from eet file. So the structure should be deleted by the user of the function.
As eet_data_read() api documentation dosen't specify about the ownership I guess
we need to free this structure to avoid memory leak.
Summary:
Multiple gradients can be declared.
There is a problem of keeping only one gradient information
when it is declared outside defs or when defs is not declared.
It supports the use of multiple gradients even if no defs are declared.
Test Plan:
(with D9312 patch)
cd src/example/edje
edje_cc -beta svg.edc && gcc -o svg-test svg-test.c `pkg-config --libs --cflags evas ecore ecore-evas edje`
./svg-test
Reviewers: Hermet, kimcinoo, smohanty
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9315
This support Android 9 patch file format. Only black is a recognized color for both
the stretch area and the content area. All other color are associated with being
"white".
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9103
This is just the plumbing that feed data provided along android 9 patch image for example
into Evas object image new stretch and content region infrastructure for rendering them
properly.
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9102
Any svg node could have its opacity value, we missed implementing it.
If a node have a opacity, it's opacity could be multiply with fill and stroke colors.
@fix
the problem was that the savers are defining the same defines as the
loaders. Because of me beeing paranoid, i would like to keep the double
define, as later on, someone will likely forget it, and it does not do
any harm here.
this fixes ci.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D9174
Summary:
Introduce a new evas json loader to support lottie animation.
This json loader uses rlottie library which is a new github open project.
These days most ui frameworks (windowpws, skia, qt, xamarin, react, nativescript) supports lottie,
the rlottie was designed to support lottie as a standalone library and compatible with efl as well.
To enable this,please install rlottie library then remove json disabler in meson_options.txt
For more information, See lottie/rlottie project and its a introdcution article:
https://airbnb.io/lottie/#/https://github.com/samsung/rlottiehttps://hermet.pe.kr/143
Co-authored-by: JunsuChoi <jsuya.choi@samsung.com>
{D8941}
{D8944}
Reviewers: #committers, jsuya, bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8940
Summary:
in gl engines, orientation is applied during the draw. this is different from
sw engines where the orientation is directly applied to the internal pixel data
which results in a state change of the object internals.
this preserves image cache state and allows the image to be loaded normally instead
of displaying a black rectangle if orientation is set prior to a texture being
created
@fix
Depends on D8916
Reviewers: Hermet, cedric
Reviewed By: Hermet, cedric
Subscribers: Hermet, cedric, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8918
Summary:
this occurs when orientation is set during image construction
@fix
Reviewers: segfaultxavi, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl_rendering
Differential Revision: https://phab.enlightenment.org/D8916
Summary:
This patch improves png quality when image uses scale-down at image loading.
Since current scale-down logic just works like point sampling,
image result could be wholely different,
Simply, if source data is consist of continous white and black pixels,
and scale down factor is 2, the sampled data would be only white,
and lose all black pixels, or vice versa.
The result can be unexpected by users.
Even current jpeg scale-down works with interpolation.
Before:
{F3711651}
After:
{F3711652}
Original:
{F3711653}
Reviewers: cedric, raster, #committers, kimcinoo, jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8788
there are some specific defines and cflags needed for these builds
to succeed and provide the expected functionality
Depends on D8733
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D8734
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
Summary:
This patch improves png quality when image uses scale-down at image loading.
Since current scale-down logic just works like point sampling,
image result could be wholely different,
Simply, if source data is consist of continous white and black pixels,
and scale down factor is 2, the sampled data would be only white,
and lose all black pixels, or vice versa.
The result can be unexpected by users.
Even current jpeg scale-down works with interpolation.
Before:
{F3711651}
After:
{F3711652}
Original:
{F3711653}
Reviewers: cedric, raster, #committers, kimcinoo, jsuya
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8788
Previously, mannual scale down logic was too primitive,
it copied pixel data each channels. Obviously, it's ineffective.
We know the general case - 4 bytes channel which is the most usage,
If loader copies data per four bytes, instructions could be reduced.
When I load scale-downed image(original 8k), about 0.02 secs was reduced by this.
Evas module loading code assumes engines are installed in
evas/modules/engines.
As part of the fixes building evas with meson, the engines are under a
subproject named evas/engines, causing the modules to be installed in
libdir/evas/engines/modules by default.
This commit adds a override of the directory the engine modules are
installed to use the correct location.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8693
the directory it was installed to was <prefix>/include/evas/engine-1/
instead of <prefix>/include/evas-1/ which is wrong. This fixes
enlightenment building.
Reviewed-by: Lauro Neto <lauromauro_>
Differential Revision: https://phab.enlightenment.org/D8692
Double check patch again, since my wrong logical thinking,
Every width must be considered to rounding up fiting 8 bits.
this new compuation must be correct.
Revert "evas wbmp: remove unnecessary size overflow."
This reverts commit 1061d0a751.
Revert "evas image: check format more strong way for wbmp."
This reverts commit 68fe9ec6bf.
this caused wbmp files to no longer be loadable
ref T7824
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8689
wbmp format doesn't have any tags for verifying file header,
It's easy to pass other format headers if they have the first 1 byte 0x0,
This ocassionally brings wrong result (= succeeed loading image),
if unknown file format is tried.
So, to make it sure, here verify the size of image additionally.
if the image size is not expected, It returns fail as the result.
This problem is actually happened in this scenario.
open any mpeg file with elm_image.
elm_image_file_set() will return true though it fails to read data.
since wbmp make it pass to succeed.
@fix
Summary:
it FINALLY happend! With this python bindings should be able to work
again with a meson build, you can also enable b_lundef right now. And it
appears to work, with this we can also get another step closer to a
windows build.
Depends on D8669
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8670
Summary:
this is required later on, where we want to build the engines
undependend from image loaders etc.
Depends on D8668
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8669
Summary:
with this we don't have any static module anymore in the engine
directory. This means either *all* modules in the enignes directory are
static OR shared. There is no mixture anymore. This is a requirement for
the directory to be build whenever we want it to be build.
Depends on D8667
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8668
Summary:
sooo, gl_common stuff is only used by gl_generic, (and maybe others.
However, it is build static anyways and only linked into gl_generic).
This means, only software_generic is still in here and we can remove one
special case from the build instructions.
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8667
Summary:
Svg parser gets transformation matrix information from svg.
If there is a matrix, calculate matrix operations
on the start and end points of the gradient.
TODO: We should implement gradientTransform of radialGradient.
Test Plan: N/A
Reviewers: Hermet, smohanty
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8663
Summary:
x1, y1, x2 and y2 of Svg_Linear_Gradient structure must be a percentage value.(0 ~ 1)
but these variables are reused with efl_gfx_gradient_linear_start/end_set/get
and duplicate operations occur.
Test Plan: N/A
Reviewers: Hermet, smohanty
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8662
Summary:
GL engine has used integer coordinates system since it's born though
OpenGL basically uses floating point vertex coordinates system.
There were many dissatisfaction, complaints about this
since object's transition is jiggled, not perfectly smooth.
It's obvious because Positioning must be stepping with integer units
without any subpixel rendering.
Our gl engine currently supports msaa options and evas map allows to
have double precivion coordinates system, our engine must do handle this over as well,
to work together.
If you don't like change,
We could switch behaviors optionally (turn on, only when msaa is enabled)
But I think it's pointless using integer coordinates system in GL thesedays.
It just make code complex to maintain.
There will be an additional patch coming for SW backend map behavior soon.
Left: before patch
Right: after patch
{F3694624}
Reviewers: #committers, raster
Reviewed By: #committers, raster
Subscribers: raster, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8552
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)
Summary:
Even if linear or radius gradient is declared,
it will not be output if there is no <defs/>
It can be supported because it stores the declared gradient in loader.gradient.
Test Plan: N/A
Reviewers: Hermet, smohanty
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8591
Summary:
The initial value of gradientUnits is objectBoundingBox.
If userSpaceOnUse is declared, change user_space to true.
We do not have to recalculate each value by this change.
The default unit for linear x1, y1, x2, y2 is percentages.
This can be a value from 0 to 1. If svg want to use a value between 0 and 100, it must have a '%' symbol
That is accroding to gradientUnits in here
https://www.w3.org/TR/2015/WD-SVG2-20150915/pservers.html#LinearGradientElementGradientUnitsAttribute
Test Plan:
cd ./src/examples/edje
edje_cc -beta svg.edc && gcc -o svg-test svg-test.c `pkg-config --libs --cflags evas ecore ecore-evas edje`
Reviewers: Hermet, smohanty
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8589
Summary:
The default unit of gradient value is percentage.
This can be a value from 0 to 1.
If svg use the '%' symbol, we must divide by 100.
And it must be calculated the same as any other case.
Test Plan: N/A
Reviewers: Hermet, smohanty
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8590
Summary:
there have been wrong function calls, that did not work at all, since
the function pointer had the wrong type. This fixes the segfaulting
examples of evas3d. However, they still do not render, at least, they
don't crash anymore.
Depends on D8381
Reviewers: cedric, segfaultxavi, zmike, stefan_schmidt
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8382
Summary:
This patch implements engine support for outbuf_damage_region_set that
we can use to mark a framebuffer as being dirty, and to set the dirty
regions on that framebuffer.
ref T7690
Depends on D8403
Reviewers: raster, cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7690
Differential Revision: https://phab.enlightenment.org/D8404
Summary:
Don't use redraws_clear to handle buffer swapping. Buffer swapping
should be done on outbuf_flush. This patch fixes evas drm software
output rotation (along with other patches in the series).
ref T7690
@fix
Depends on D8402
Reviewers: raster, cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7690
Differential Revision: https://phab.enlightenment.org/D8403
Summary:
We don't need to use eng_output_resize in this engine as
eng_output_update will take care of that. Also, don't use
redraws_clear to handle buffer swapping. This is part one of software
rotation fixes.
ref T7690
@fix
Depends on D8116
Reviewers: raster, cedric, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7690
Differential Revision: https://phab.enlightenment.org/D8402
example:
...
im=evas_object_image_add()
evas_gl_surface_create
...
evas_object_image_native_surface_set(im, xx)-> MAIN CONTEXT
evas_gl_make_current -> CONTEXT A
.....
evas_object_image_size_set(im, x,x) ->WRONG CONTEXT A
evas_object_image_size_set of image have native_surface finally calls
eng_image_size_set function of gl_generic.
eng_image_size_set cannot get the proper context related with
evas_gl_common_image_native_enable.
It ruined gl context and texture of main context has gone wrong.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8338
Here is a replacement to use eina_file from a vg obj instance
to map file data by vg loaders.
This brings a benefit that integrated access to load data
between vg object and vg loaders.
Summary:
This enables all the checks unconditionally, without ignoring
classes that don't have an Efl namespace. This required a lot
of beta marking to make it build. It most likely doesn't
mark types correctly, as that is not fully enabled yet.
Reviewers: zmike, cedric, segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8266
When we call evas_outbuf_reconfigure (when rotation changes), we need
to update the Outbuf with new values for width, height, rotation, etc.
Failing to do this here causes any rotations applied to the engine to
fail.
ref T7690
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8109
the source should be used in the dependency. However, only the generated
header source, not the .c files or we will get duplicated sources.
This is another attempt to fix the build OSX travis failure
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7896
There was the problem that evas_ector_software_buffer.eo was not arround
but required by the gl_generic engine, this fixes that by adding the
generated source and dependencies to the software_generic dependency.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7871
Summary: This fixes especially the execution of edje_cc on Windows
Test Plan: execution of edje_cc
Reviewers: cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7834
the error
```
./src/modules/evas/engines/gl_generic/../software_generic/evas_ector_software.h:31:10: fatal error: 'evas_ector_software_buffer.eo.h' file not found
```
Came up when building efl on osx with meson. This is caused by the fact that gl_generic was build before the .eo files of evas_ector have been created in software_generic, this fixes this race condition by adding a new dependency to avoid that.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D7831
this came up on travis with osx. However, it should hit everyone, and
its questionable why it did not happened ever before.
Differential Revision: https://phab.enlightenment.org/D7831
We looked this up with dlsym, so I guess we should use that even though
the direct call seems to work just fine most of the time.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7433
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
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
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:
Map context missed setting texture target.
I guess this is one of regression bugs in gl backend.
When shader is flushed, it sets invalid texture target with map texture.
That caused blank map rendering, this could be observed temporary
because gl pipe contexts are reusable and missing texture target means,
it could use previous texture target values that mostly have GL_TEXTURE_2D.
@fix
Reviewers: #committers, ManMower
Reviewed By: #committers, ManMower
Subscribers: ManMower, cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6818
Summary:
Here opened eina file is just leaked.
close it properly.
@fix.
Reviewers: devilhorns, #committers, zmike
Reviewed By: #committers, zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6549
Summary:
In fixing T7099 I've also allowed the buffer queue to grow quite large,
so now we should prune it back if it's bigger than it needs to be for
a long time.
ref T7099
Depends on D6565
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7099
Differential Revision: https://phab.enlightenment.org/D6566
Summary:
It's no longer needed in the header because it doesn't change
the size of the structures there anymore.
Depends on D6564
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6565
Summary:
Instead of allocating a fixed number of buffers immediately, allocate
buffers if needed to render to.
Normally we only need 2 buffers, but we've been allocating 3 to handle
worse case behaviour. As T7099 shows, this is not always enough. We
now cap at a max of 10.
For the normal case where we always use 2 this results in a slight
memory reduction (1 buffer) and a slight renering load reduction
because we pick the oldest buffer to render into.
A future patch will trim the buffer queue if it's been too large for
a long time.
fix T7099
Depends on D6563
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7099
Differential Revision: https://phab.enlightenment.org/D6564
Summary:
This is just a step towards making it a variable length.
ref T7099
Depends on D6562
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7099
Differential Revision: https://phab.enlightenment.org/D6563
Summary:
Use pointers instead of an array of structures, since we're going to
replace the array with a list shortly.
ref T7099
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7099
Differential Revision: https://phab.enlightenment.org/D6562
this has been going on for a while. on nvidia drivers in gles mode on
x11 there is a massive perf drop to like a few fps with enough windows
if we build for egl/gles instead of opengl. it was the re-creating of
eglimages every frame. put a vendor specific workaround for this and
avoid it. it's not needed there anyway. framerate back to 60fps
smoothness afterwards.
@fix
Summary:
We need to be able to forcibly destroy all surface buffers to make
session recovery work safely for software rendering.
@betabreak
Depends on D6278
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6279
Summary:
this is a longstanding issue which was exposed by recent patches to standardize
object lifecycles. when a native surface is used by multiple images, unsetting
the surface from one image must not destroy the native surface or else the
remaining images
fix T6970
@fix
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6970
Differential Revision: https://phab.enlightenment.org/D6235
Summary:
code was added which ignores the comment explicitly warning not to
do what was done here
ref 9e01cf2698
ref T6970
==4829== Invalid read of size 1
==4829== at 0x246D8F06: evas_gl_common_image_update (evas_gl_image.c:907)
==4829== by 0x246DAA7B: evas_gl_common_image_draw (evas_gl_image.c:1417)
==4829== by 0x246A2AB6: eng_image_draw (evas_engine.c:1240)
==4829== by 0x6A87842: _draw_image (evas_object_image.c:1403)
==4829== by 0x6A8A1BF: _evas_image_render (evas_object_image.c:2171)
==4829== by 0x6A890C1: evas_object_image_render (evas_object_image.c:1868)
==4829== by 0x6B09C82: evas_render_mapped (evas_render.c:2292)
==4829== by 0x6B0CE90: evas_render_updates_internal_loop (evas_render.c:3079)
==4829== by 0x6B0EACA: evas_render_updates_internal (evas_render.c:3522)
==4829== by 0x6B1087C: evas_render_updates_internal_wait (evas_render.c:3946)
==4829== by 0x6B10A4D: _evas_canvas_render_updates (evas_render.c:3971)
==4829== by 0x6A7A234: evas_canvas_render_updates (evas_canvas.eo.c:212)
==4829== by 0x6A7BBD4: evas_render_updates (evas_canvas.eo.c:758)
==4829== by 0x808A7D8: ecore_evas_render (ecore_evas.c:177)
==4829== by 0x808AA58: _ecore_evas_idle_enter (ecore_evas.c:284)
==4829== by 0x5CC1E46: _ecore_call_task_cb (ecore_private.h:442)
==4829== by 0x5CC1EAE: _ecore_factorized_idle_process (ecore_idler.c:35)
==4829== by 0xBFA4DD4: _event_callback_call (eo_base_class.c:1663)
==4829== by 0xBFA50A6: _efl_object_event_callback_call (eo_base_class.c:1747)
==4829== by 0xBFA514C: efl_event_callback_call (eo_base_class.c:1750)
==4829== by 0x5CC661B: _ecore_main_loop_iterate_internal (ecore_main.c:2352)
==4829== by 0x5CC3F65: _ecore_main_loop_begin (ecore_main.c:1175)
==4829== by 0x5CCC856: _efl_loop_begin (efl_loop.c:83)
==4829== by 0x5CCEF6D: efl_loop_begin (efl_loop.eo.c:28)
==4829== by 0x5CC40DF: ecore_main_loop_begin (ecore_main.c:1248)
==4829== by 0x5480EE: main (e_main.c:1090)
==4829== Address 0x2bfc30f8 is 328 bytes inside a block of size 560 free'd
==4829== at 0x4C30D18: free (vg_replace_malloc.c:530)
==4829== by 0x540AE91: _eina_freeq_free_do (eina_freeq.c:118)
==4829== by 0x540B7B0: eina_freeq_ptr_add (eina_freeq.c:372)
==4829== by 0x6BCD23C: _evas_common_rgba_image_delete (evas_image_main.c:555)
==4829== by 0x6B41538: _evas_cache_image_entry_delete (evas_cache_image.c:205)
==4829== by 0x6B43503: evas_cache_image_drop (evas_cache_image.c:945)
==4829== by 0x6B43F4F: evas_cache_image_size_set (evas_cache_image.c:1166)
==4829== by 0x246D6548: evas_gl_common_image_alloc_ensure (evas_gl_image.c:17)
==4829== by 0x246D8EA8: evas_gl_common_image_update (evas_gl_image.c:869)
==4829== by 0x246DAA7B: evas_gl_common_image_draw (evas_gl_image.c:1417)
==4829== by 0x246A2AB6: eng_image_draw (evas_engine.c:1240)
==4829== by 0x6A87842: _draw_image (evas_object_image.c:1403)
==4829== by 0x6A8A1BF: _evas_image_render (evas_object_image.c:2171)
==4829== by 0x6A890C1: evas_object_image_render (evas_object_image.c:1868)
==4829== by 0x6B09C82: evas_render_mapped (evas_render.c:2292)
==4829== by 0x6B0CE90: evas_render_updates_internal_loop (evas_render.c:3079)
==4829== by 0x6B0EACA: evas_render_updates_internal (evas_render.c:3522)
==4829== by 0x6B1087C: evas_render_updates_internal_wait (evas_render.c:3946)
==4829== by 0x6B10A4D: _evas_canvas_render_updates (evas_render.c:3971)
==4829== by 0x6A7A234: evas_canvas_render_updates (evas_canvas.eo.c:212)
==4829== by 0x6A7BBD4: evas_render_updates (evas_canvas.eo.c:758)
==4829== by 0x808A7D8: ecore_evas_render (ecore_evas.c:177)
==4829== by 0x808AA58: _ecore_evas_idle_enter (ecore_evas.c:284)
==4829== by 0x5CC1E46: _ecore_call_task_cb (ecore_private.h:442)
==4829== by 0x5CC1EAE: _ecore_factorized_idle_process (ecore_idler.c:35)
==4829== by 0xBFA4DD4: _event_callback_call (eo_base_class.c:1663)
==4829== by 0xBFA50A6: _efl_object_event_callback_call (eo_base_class.c:1747)
==4829== by 0xBFA514C: efl_event_callback_call (eo_base_class.c:1750)
==4829== by 0x5CC661B: _ecore_main_loop_iterate_internal (ecore_main.c:2352)
==4829== by 0x5CC3F65: _ecore_main_loop_begin (ecore_main.c:1175)
==4829== by 0x5CCC856: _efl_loop_begin (efl_loop.c:83)
==4829== by 0x5CCEF6D: efl_loop_begin (efl_loop.eo.c:28)
==4829== by 0x5CC40DF: ecore_main_loop_begin (ecore_main.c:1248)
==4829== by 0x5480EE: main (e_main.c:1090)
==4829== Block was alloc'd at
==4829== at 0x4C31A1E: calloc (vg_replace_malloc.c:711)
==4829== by 0x6BCCF2F: _evas_common_rgba_image_new (evas_image_main.c:509)
==4829== by 0x6B41588: _evas_cache_image_entry_new (evas_cache_image.c:261)
==4829== by 0x6B44861: evas_cache_image_empty (evas_cache_image.c:1447)
==4829== by 0x246D845B: evas_gl_common_image_native_disable (evas_gl_image.c:624)
==4829== by 0x253F3C09: eng_image_native_set (evas_engine.c:1234)
==4829== by 0x6A86204: _evas_image_native_surface_set (evas_object_image.c:1021)
==4829== by 0x6A7E110: evas_object_image_native_surface_set (evas_image_legacy.c:509)
==4829== by 0x6A8609A: _on_image_native_surface_del (evas_object_image.c:998)
==4829== by 0x6A55190: _eo_evas_object_cb (evas_callbacks.c:184)
==4829== by 0xBFA4EB7: _event_callback_call (eo_base_class.c:1686)
==4829== by 0xBFA51F8: _efl_object_event_callback_legacy_call (eo_base_class.c:1759)
==4829== by 0xBFA529E: efl_event_callback_legacy_call (eo_base_class.c:1762)
==4829== by 0x6A968ED: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1229)
==4829== by 0xBFA529E: efl_event_callback_legacy_call (eo_base_class.c:1762)
==4829== by 0x6A55C3D: evas_object_event_callback_call (evas_callbacks.c:413)
==4829== by 0x6A96D3E: _efl_canvas_object_efl_object_invalidate (evas_object_main.c:1279)
==4829== by 0xBFA7BAB: efl_invalidate (efl_object.eo.c:72)
==4829== by 0xBFA0A09: _efl_invalidate (eo_base_class.c:170)
==4829== by 0xBFA2737: _efl_object_parent_set (eo_base_class.c:734)
==4829== by 0xBFA6BDA: efl_parent_set (efl_object.eo.c:12)
==4829== by 0xBFA2537: efl_del (eo_base_class.c:686)
==4829== by 0x6A96082: evas_object_del (evas_object_main.c:1041)
==4829== by 0x2C9D519F: _bar_icon_preview_del (bar.c:762)
==4829== by 0x6A55190: _eo_evas_object_cb (evas_callbacks.c:184)
==4829== by 0xBFA4EB7: _event_callback_call (eo_base_class.c:1686)
==4829== by 0xBFA51F8: _efl_object_event_callback_legacy_call (eo_base_class.c:1759)
==4829== by 0xBFA529E: efl_event_callback_legacy_call (eo_base_class.c:1762)
==4829== by 0x6A968ED: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1229)
==4829== by 0xBFA529E: efl_event_callback_legacy_call (eo_base_class.c:1762)
==4829== by 0x6A55C3D: evas_object_event_callback_call (evas_callbacks.c:413)
==4829== by 0x6A96D3E: _efl_canvas_object_efl_object_invalidate (evas_object_main.c:1279)
==4829== by 0xBFA7BAB: efl_invalidate (efl_object.eo.c:72)
==4829== by 0x7BE9326: _efl_access_object_efl_object_invalidate (efl_access_object.c:634)
==4829== by 0xBFA7BAB: efl_invalidate (efl_object.eo.c:72)
==4829== by 0xBFA0A09: _efl_invalidate (eo_base_class.c:170)
==4829== by 0xBFA2737: _efl_object_parent_set (eo_base_class.c:734)
==4829== by 0xBFA6BDA: efl_parent_set (efl_object.eo.c:12)
==4829== by 0xBFA2537: efl_del (eo_base_class.c:686)
==4829== by 0x6A96082: evas_object_del (evas_object_main.c:1041)
==4829== by 0x7CD5F2C: _efl_ui_widget_efl_canvas_group_group_del (efl_ui_widget.c:855)
==4829== by 0x6AAD303: efl_canvas_group_del (evas_object_smart.c:1862)
==4829== by 0x7AFF104: _elm_box_efl_canvas_group_group_del (elm_box.c:362)
==4829== by 0x6AAD303: efl_canvas_group_del (evas_object_smart.c:1862)
==4829== by 0x6AABB79: evas_object_smart_del (evas_object_smart.c:1288)
==4829== by 0x6A97179: _efl_canvas_object_efl_object_invalidate (evas_object_main.c:1336)
==4829== by 0xBFA7BAB: efl_invalidate (efl_object.eo.c:72)
==4829== by 0x7BE9326: _efl_access_object_efl_object_invalidate (efl_access_object.c:634)
==4829== by 0xBFA7BAB: efl_invalidate (efl_object.eo.c:72)
==4829== by 0xBFA0A09: _efl_invalidate (eo_base_class.c:170)
==4829== by 0xBFA2737: _efl_object_parent_set (eo_base_class.c:734)
==4829== by 0xBFA6BDA: efl_parent_set (efl_object.eo.c:12)
==4829== by 0xBFA2537: efl_del (eo_base_class.c:686)
==4829== by 0x6A96082: evas_object_del (evas_object_main.c:1041)
==4829== by 0x2C9D41DA: _bar_icon_preview_hide (bar.c:450)
==4829== by 0x5CFE14C: _ecore_call_task_cb (ecore_private.h:442)
==4829== by 0x5CFE5C4: _ecore_timer_legacy_tick (ecore_timer.c:160)
==4829== by 0xBFA4DD4: _event_callback_call (eo_base_class.c:1663)
==4829== by 0xBFA50A6: _efl_object_event_callback_call (eo_base_class.c:1747)
==4829== by 0xBFA514C: efl_event_callback_call (eo_base_class.c:1750)
==4829== by 0x5CFF880: _efl_loop_timer_expired_call (ecore_timer.c:634)
==4829== by 0x5CFF6AF: _efl_loop_timer_expired_timers_call (ecore_timer.c:587)
==4829== by 0x5CC6522: _ecore_main_loop_iterate_internal (ecore_main.c:2317)
==4829== by 0x5CC3F65: _ecore_main_loop_begin (ecore_main.c:1175)
==4829== by 0x5CCC856: _efl_loop_begin (efl_loop.c:83)
==4829== by 0x5CCEF6D: efl_loop_begin (efl_loop.eo.c:28)
==4829== by 0x5CC40DF: ecore_main_loop_begin (ecore_main.c:1248)
==4829== by 0x5480EE: main (e_main.c:1090)
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6234
Summary:
This hasn't been useful in a very long time.
Depends on D6120
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6121
Summary:
I don't even know what to put here, but I'll try.
wl_egl_window_resize()'s final two parameters indicate new attachment
points for a buffer relative to the previous top left corner. When the
compositor is resizing a window it already handles the corner placement.
Fortunately, compositors seem to ignore the new attach co-ords during
resize, so this code hasn't broken anything. It's just a complicated
NOP.
The new attachment points are intended for use in spontaneous resize,
not drag resize, but the only time these functions are called is for
drag resize.
Depends on D6119
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6120
Since we don't actually set the color depth at all we can end up with
an RGB565 buffer. We don't ask for depths because apparently the N900
had a problem with this under X.
I'm not aware of any efforts to bring wayland to the N900, so let's do
this normally.
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
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary: disp is written twice with the same value.
Test Plan: N/A
Reviewers: woohyun, kimcinoo, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5874
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
strstr() can give false positives if the extension name is a subset of
a string in the extension list, for example EGL_EXT_image_dma_buf_import
would match EGL_EXT_image_dma_buf_import_modifiers.
I've opted for a mildly badgered copy of epoxy's test, which should be
robust in the face of subsets.
Anything non-EGL we might query would have to be queried here, so
I'm moving the call here to protect us in the event that we need GL
extensions in the future.
I'm still a bit confused as to what string I should be passing to
evas_gl_symbols, though.
This is a hint that we want a high priority context. Since gl_drm is
likely a compositor or a full screen app, it makes sense that it try to
use this (but other engines probably shouldn't)
Based loosely on Chris Wilson's weston patch to do the same thing.
(weston commit b678befb6ed055e6c66466505d9195a3cebf8073)
As this extension appears to have been around for years, I haven't
added fallback defines for:
EGL_CONTEXT_PRIORITY_LEVEL_IMG 0x3100
EGL_CONTEXT_PRIORITY_HIGH_IMG 0x3101
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>
We already include the Ecore_Drm2 header for these engines, so there
is no need for the 'output' field to be a void pointer here.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The dirty bit was a dirty hack to let session recovery force reconfigures
on startup.
Now that we have a surface flush we can achieve the same thing by just
discarding all buffers immediately.
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
This is very useful to specify precisely which kind of RGBA -> Alpha
conversion you want. If all you wanted was the alpha layer to use as a
mask, set this flag to true.
@feature
Summary:
The Encoding key is no longer required, all desktop files are assumed to
be UTF-8 encoded. See details at:
https://standards.freedesktop.org/desktop-entry-spec/1.1/apc.html
Fix various typos and misspellings
lintian, Debian's package checker, uses strings to check for common typos
in compiled binaries. This change fixes the ones it identified in 1.20.6.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5584
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This small patch just checks that we have a valid surface and bo that
we can pass to gbm_surface_release_buffer. If they are not valid, this
causes a hard crash.
NB: This does not actually Fix the ticket issue....
ref T6483
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Shinwoo Kim
Carsten Haitzler
Hermet Park
junsu choi
Boris Faure
Marcel Hollerbach
Vincent Torri
Daekwang Ryu
SubhransuSekhar Mohanty
Cedric BAIL
Mike Blumenkrantz
Lauro Moura
abdulleh Ghujeh
Christopher Michael
Jiyoun Park
Daniel Kolesa
Marcel Hollerbach
Daniel Kolesa
Ali Alzyod
Derek Foreman
Derek Foreman
Xavi Artigas
Bowon Ryu
Daniel Kolesa
WooHyun Jung
Cedric BAIL
Youngbok Shin
Jean-Philippe Andre
Marcel Hollerbach
Ross Vandegrift
Pawel Aksiutowicz
