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