Reset the Outbuf's Engine information pointer.
We also don't need to do an eng_window_free during reconfigure because the
software_generic_update function will free it anyway.
We should also re-setup the tilebuffer during eng_setup.
Fix gl_context resize to work even if there is no wl_egl window setup
yet.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This is the first part of the wayland-egl engine fix. Don't resize the
gl_context during the first_rectangle function, and don't set any
preserve bits on the gl_context
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we fail to init gl_generic then we should cleanup properly and free
the recently created Outbuf.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fix T1459. I have added an ERR to catch this kind of issue earlier.
I am wondering if that should not be even a CRI.
The reason why we do see the problem only after the introduction of the
use of Eina_Rectangle_Pool is due to how efficiently they pack data, resulting
in ressource ending up in the wrong format bucket. Nothing wrong with the
patch itself.
Summary:
@fix
Segfault in wayland_egl engine is casused by illegal library linking.
Fix this by linking to GLESv2 and EGL libraries.
Test Plan: N/A
Reviewers: devilhorns, raster, cedric, Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1332
several loaders make too much noise when a file fails to load - almost
all of this is because the file isnt actually an image format file at
all, and an ap is just asking evas to try do a load to see if it is a
loadable image at all. this results in noisy strerr output that simply
shouldnt be there. so silence for loaders. @fix
i found that we are not setting u and v to be smooth (linear
interpolate) for yuv reendering, even when asked. they remain at a
default "nearest". this enables linear for u and v always, meaning
even when smooth is off, we still interpolate u and v (not y), and
even when at 1:1 with no scaling u and v get interpolation for better
quality.
@fix!
since colors are hex, 96 bytes of hex would be 32bytes per r, g and b,
and that would be 128 bits per r g and b and that just is never seen
or used. also coverity is right in CID 1193201 that we just can't
shift that many, so go down to max 16 bits per rgb which is sensible
and able to be done. (thats 12 bytes max for hex of color).
We cannot use the texture to find a valid format Before the texture is
actually created. This is invalid, leads to "warning: tex is used
uninitialized' message from the compiler, and just plain wrong.
Instead, use the alpha property of the Evas_GL_Image to find the
proper texture format, Then create the texture.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so in fixing one CID for a format lookup failing and thus invalid mem
access, a possible leak was made in this case. fix that by doing
lookup before any allocation and if lookup fails, return there
this fixes CID 1230999 1230998 1230997
gl_generic functions expect the Outbuf to contain the canvas, so we
fixed the eng_window_new function to accept that, And the engine info.
This simplifies the calls to eng_window_new.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Since we simplified the eng_window_new function to accept the canvas
and engine info, we need to update calls to that function
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We need to pass in the canvas and engine info structure as the
gl_generic engine needs the outbuf->canvas to be set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Evas wayland_egl engine crashes on startup when it is running with mesa.
Evas is trying to get EGL / GLES extension function addresses where evas_gl_symbols.
It is called before eglGetDisplay. Then mesa considers that current egl platform is
X11 if it has no EGL_PLATFORM env var. This behavior of mesa is bad. But we should
provide workaround until it is fixed. Thus EGL_PLATFORM env var should be defined to
wayland before calling eglGetProcAddress.
@fix
Test Plan: run elementary_test under wayland with wayland_egl engine.
Reviewers: raster, stefan_schmidt, devilhorns
Reviewed By: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1312
Seems the newer wayland-egl code was missing the log domain variable
and thus would not load at time of dlsym due to missing symbol. This
fixes that problem by defining the variable.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We are already using the pointer before we check it here. We also don't
check it in the other callbacks so align the handling in this file.
CID: 1039635, 1039636, 1039637, 1039638, 1039639
these were static rect cutouts, so they stayed around on exit and thus
we "lost" them. this nukes them on context free and each new frame.
fixes the "leak"
The eng_gl_context functions are used for Evas 3D, so let's support
those in the wayland_egl engine.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previous (french) changes to evas_gl code broke the wayland egl engine. This
batch of changes fixes that by rewriting to engine to work with new
evas_gl functions.
Fixes Phab ticket T1478
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Recent changes to evas engines require using evas_gl_generic now, so
let's sort out the headers and include the gl_generic one we need
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Plug image is displayed incorrect after connect to socket.
Test case: Run ecore_evas_extn_socket_example -> run ecore_evas_extn_plug_example -> click Change bg to change bg color.
Run 2nd ecore_evas_extn_plug_example. The plug area image of 2nd plug is incorrect display (different with 1st plug image).
Reason: When a plug connects to socket, socket sends incorrect buffer information.
Fix: Change buffer information.
@fix
Reviewers: Hermet, huchi
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1232
We allocate a new eina_rectangle here, but we never free it after
sending damages to the surface.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
ico files were defined to have bmp's in each key - in fact a subset of
them. unbenknownst to yours truly, vista now allows them to also be
pngs and thus the ico loader rejects them as corrupt. at least detect
it and complain right now
We use this functionality already from ecore_drm. The evas version does
not even use udev to acquire the device which means we could not support
hotplugging. The only missing feature was the capability check for
DUMB_BUFFER which I added to ecore_drm now.
This is the second iteration of this patch. Thsi time also taking expedite
runs of he evas drm engine in account.
Note that we can't access gl_common directly as it is not possible to link it
2 times. I also didn't want to force evas to be linked with GL/EGL. So I rely
now on dlsym on about 20 symbols to get that backend going.
This is the first step to introduce a common gl infrastructure for all gl based backend.
For now it is strictly doing the exact same thing that the gl_x11 was doing, but I already
spoted that a lot of the optimization in gl_x11 where not incorporated in other gl backend.
So this is going to help everyone by sharing more code on a crucial part of our infrastructure.
This reverts commit 5e18223f67.
Conflicts:
src/modules/evas/engines/gl_common/evas_gl_context.c
we've got a side effect(another quality issue) of the patch. so revert it.
Masking is not used (there even was a recent commit by Hermet to
remove most of the occurences of mask shaders in GL), and I've
introduced a new ETC1+Alpha feature. Replace the old texm and
associated variables by texa for alpha texures.
Summary: Add support for canvas resizing: the window was resizable but its content was not resized.
Reviewers: raster, raoulh, naguirre, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1163
Software Generic backend can send us OUTBUF_DEPTH_INHERIT during a
reconfigure. If we are inheriting the previous depth, let's check that
so we don't get needless destrouction/recreation of shm buffers.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Seems the new software_generic backend is passing in
OUTBUF_DEPTH_INHERIT during a reconfigure, so let's add a check for
that else if not, the entire drm engine stops rendering due to output
buffers not being created to match the framebuffer depth.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Adjust the ob->w/h dimensions After the framebuffer has been setup
because we cannot have output buffers smaller than the framebuffer
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We cannot use epd->output.w/h in these calls as the setup of the
output buffer May cause a resize. Drm buffers cannot be allocated
Smaller than the framebuffer size, so evas_drm_outbuf_setup function
May resize the ob->w/h to match the framebuffer.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
When a client is added to socket server, socket server sends NBUF (2) times of OP_RESIZE, OP_UPDATE, OP_UPDATE_DONE messages to client. However, only one message of OP_RESIZE, OP_UPDATE, OP_UPDATE_DONE is enough.
This patch removes redundant OP_RESIZE, OP_UPDATE, OP_UPDATE_DONE sending.
Reviewers: raster, Hermet
Reviewed By: Hermet
CC: woohyun, huchi
Differential Revision: https://phab.enlightenment.org/D1141
Eeeeh. Not only we don't support atlasses with this RGB+A thing
yet, but ETC1 does not even support SubImage2D (according to the
current spec).
Also, fix a few typos in that same function.
Some colorspaces (ETC, S3TC, GRY, ...) don't care about the value
of BGRA support or the alpha flag. So, let's introduce the
new boolean^Wenum value MATCH_ANY ;)
Note: the compressed texture formats with alpha support have been
marked as matching both TRUE and FALSE for alpha. The images
should always have the alpha flag set to TRUE, though.
The BGRA flag really doesn't matter.
The TGV loader is an Evas_Loader, not part of evas itself
(eg. in cserve), so we can't use evas functions from there.
eina_cpu provides appropriate CPU features detection.
Save images with alpha in two planes:
- RGB data as ETC1
- Alpha as ETC1 (from a greyscale image)
The second plane alpha is located right after the RGB plane.
The RGBA data is not premultiplied, so that RGB can be encoded
at a better quality in ETC1. This should avoid some blockiness
artifacts that we can see in the current ETC2 mode (which supports
alpha natively). Eventually ETC2 should also support non
premultiplied data for a better encoding quality.
This patch implements the saver and the loader.
@feature
These shaders take two textures as input and sample RGB from
texture 1 and alpha from texture 2. This is the non-premultiplied
version, so RGB' = RGB*A.
This includes only the GLSL code.
We need to check if evas_outbuf_setup Failed and did not return a new
ob for us to work with...so this if check was invalid
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
We need to have the drm fd & tty setup Prior to creating the output
buffer so that the output buffer knows what drm card to use
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit 31ad73efa9.
Conflicts:
src/modules/evas/engines/drm/evas_engine.c
Revert this commit as these functions are needed to run evas engine
standalone (expedite) on drm
I saw some GL error messages (with the GLERR() macro activated),
that were caused by GL_INVALID_VALUE.
For some (many) textures, tex->y was 0 but since we now use a 2D
atlas (rectangle allocator), the first row of pixels should be
repeated. This caused uploads to Y = tex->y - 1 = -1, which is
invalid.
Now, the evas loader is supposed to advertise the actual border
size in case of compressed texture formats.
The only case where the border was non zero was ETC formats,
from the TGV loader, so I think we don't need to keep the
previous behaviour (auto-calculate borders for ETC).
We use this functionality already from ecore_drm. The evas version does
not even use udev to acquire the device which means we could not support
hotplugging. The only missing feature was the capability check for
DUMB_BUFFER which I added to ecore_drm now.
Summary:
90 or 270 degree rotation is not working properly
width should be regarded as height, and vice versa.
if this patch and D1082 were commited, rotation from metadata will be working properly by using evas_object_image_load_orientation_set()
@fix
Test Plan: add image object and invoke evas_object_image_load_orientation_set() -> load file with orientation metadata -> check whether image is rotated properly or not
Reviewers: raster, cedric, jpeg
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D1084
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
To avoid texture bleeding in the texture atlas,
we adjust texture uv point as much as a half uv point.
Especially, this improves the rendering quality when the image has the border
area.
Unless apply this patch,
You might find the rendering result is different with software backened,
if the image has the borders.
In the software backened,
the border line was clear but the gl wasn't.
because the border line was interpolated so the rendering result was not the one we expected.
@fix
ecore_evas_cursor_object_set
NB: Previously, if we mad calls to ecore_evas_cursor_object_set to update the
mouse cursor hotspot, the mouse cursor would be repositioned at 0,0 on
the canvas due to x & y being set to 0,0. We fix that here by fetching
the current mouse position Regardless if we are changing the object or
not (ie: perhaps we are just updating the hotspot and not the object)
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In case of png, grayscale with transparency format (transparency doesn't mean the png has alpha channel)
gl doesn't prepare that format render.
In this case, set it argb8888 to convert the data in the png loader.
@fix
Summary:
This patch introduce various new logic for packing/unpacking of Eina Rectangle in a pool.
It is then used by Evas GL backend texture allocation to improve how efficiently we pack
image in texture atlas. This lead to improved memory usage and reduced power consumption
with usually a more stable higher FPS (as it use less texture to do the same task, their
is less texture switch, so saving memory and speed at the same time).
This patch was developped on Cedric's suggestions to optimize the packing logic using Skyline
algorithm. This patch is based on master and is a new submission for earlier phab link
https://phab.enlightenment.org/D774.
Signed-off-by: Sanjay Nirankari <sanjay.n1@samsung.com>
Signed-off-by: Rajeev Ranjan <rajeev.r@samsung.com>
Signed-off-by: Sreedeep Moulik <sreedeep.m@samsung.com>
Reviewers: cedric, raster
CC: wonsik, jpeg, sreedeep.m, sanjay, govi
Differential Revision: https://phab.enlightenment.org/D1063
Signed-off-by: Cedric BAIL <c.bail@partner.samsung.com>
NB: Don't recall what the initial point was here, but I don't see one
now lol. No real usage for checking the ecore_wl_init count anymore so
remove the variable as we don't need to do that.
@fix
Signed-off-by: Chris Michael <devilhorns@comcast.net>
ETC2 textures were allocated using the same empty slots pool
as RGBA textures.
ETC1 texture atlasses should still be tested.
An extension string is required to avoid using the bad
fallback in place right now. But there is no such thing yet.
this fixes @draisch's report of blankness, but doesn't fix the
garbage. it's something to do with the always render move in elm gl -
it just doesn't seem to be rendering before evas renders, or if it is,
it's failing to work/produce content.
ecore_evas_convert: Add -e/--encoding option
This uses directly the encoding parameter.
For now, used only by the TGV saver, but there is no other way
to specify between ETC1 and ETC2. And we don't have a mixed ETC1+2
mode (yet).
@feature
We prefer ETC2 textures when ETC2 support has been detected.
According to the spec, glCompressedTexSubImage2D should work
for ETC2.
Try even with ETC1. This may fail at runtime. The fallback path
is very dubious right now but without a proper test case I'm
not sure which approach to take.
We can also imagine cases where the GPU supports TexSubImage for
ETC1 but ETC2 is not supported at all. This will need testing, as
this case is not handled.
@feature
Summary:
For drivers that support IMG_multisampled_render_to_texture,
GL_MAX_SAMPLES_IMG should be used to query max supported samples
Likewise, for drivers that support EXT_multisampled_render_to_texture,
GL_MAX_SAMPLES_EXT should be used to query max supported samples
@fix
Reviewers: seoz, Hermet, raster, cedric
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D948
This will call the new ETC2 encoding functions.
Note that the quality and performance will be horrible, but at
least alpha should be supported.
Also, there is no way to choose between ETC1 and ETC2 from
the client API side, which, well, sucks. So ETC2 is selected
if and only if the image has alpha (according to its flag).
@feature: Encode images in ETC2 with support for Alpha (if needed).
Summary: re->win pointer was not compared with NULL pointer before re->win was referenced.
Reviewers: Hermet
Reviewed By: Hermet
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D910
Summary: The comparison gc->dc with NULL is not necessary. So the unnecessary conditional expression is removed.
Reviewers: Hermet
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D909
We can't just blindly copy the full string into a 128 byte buffer. Adding
some check here to actually stay below the buffer limit or return.
CID 1193233
In some cases, the image has a format different from RGBA,
so image_data_set will be invalid as the new data is expected to
be RGBA. This happened with ETC2 images.
Chris Michael
Cedric Bail
Carsten Haitzler
Mun Gwan-gyeong
Gwanglim Lee
Stefan Schmidt
Thiep Ha
Cedric BAIL
Vincent Torri
ChunEon Park
Jean-Philippe Andre
Jean Guyomarc'h
Dmytro Dadyka
Wonguk Jeong
Tom Hacohen
Rajeev Ranjan
Chris Michael
Raoul Hecky
Nicolas Aguirre
Dongyeon Kim
Guillaume Friloux
Doug Newgard
Jaehyun Cho
U. Artie Eoff