Enable 3D features using --enable-evas-3d=yes when configuring.
APIs are exposed through Evas_3D.h.
Currently, evas-3d is being supported only on gl_x11 engine.
Conflicts:
src/lib/evas/Evas_Eo.h
Since rg_etc1 now outputs proper BGRA data, the shaders should not
swizzle the colors around. Stick to the normal fragment shaders.
Note: This is not tested.
Since the introduction of new colorspaces for GL_X11
(GRY8, AGRY88 and ETC1), stride_get() would return
an invalid value and data_get() would just abort().
Add proper support for these functions.
ETC1 data will NOT be returned from data_get() and
stride_get() will return 0. This is to avoid people from
messing up badly with encoded color spaces.
Since the introduction of color spaces other than RGBA8888 in
the GL engines, there was an issue with border images scaled in
GL. The left and right edges were simply not properly copied.
This would then show artifacts when scaling very thin images
(typically 2px wide).
Async page flip can cause tearing, is not supported on all cards, and
apparently requires a specific libdrm patchlevel...in general, more
trouble than it's worth, so let's just remove it.
@bugfix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This symbol should be part of the loaded libraries, can be found
using dlsym, even if eglGetProcAddress() returns NULL.
Add etc1 flag in the debug output.
@bugfix: This adds some safety trapping for trying to create a canvas
below the drm framebuffer size. Drm does not support creating a canvas
smaller than the framebuffer output, so we will add some trapping to
catch that, and internally create the framebuffers to the proper size.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Warning fixed of evas
modules/evas/engines/gl_common/evas_gl_context.c: In function 'evas_gl_common_context_new':
modules/evas/engines/gl_common/evas_gl_context.c:392:32: warning: 'minor' may be used uninitialized in this function [-Wuninitialized]
modules/evas/engines/gl_common/evas_gl_context.c:314:8: note: 'minor' was declared here
modules/evas/engines/gl_common/evas_gl_context.c:392:16: warning: 'major' may be used uninitialized in this function [-Wuninitialized]
modules/evas/engines/gl_common/evas_gl_context.c:313:8: note: 'major' was declared here
@fix
Compilation Warning Fixed
Test Plan: Compile efl
Reviewers: singh.amitesh
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D656
@fix: ecore_evas_window_get expects an Ecore_Window to be returned.
Because of this, we need to have a 'window' that can be returned via
ecore_evas. For this case, we will use the output's framebuffer id as
the 'window' so we need to set that into the engine info so that
ecore_evas can fetch it.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In evas_gl_common_image_draw, if an image is drawn with a fresh context,
containing no clip and no cutouts, then it will be wrongly clipped to
the source image size instead of the destination surface size.
This case seems to never happen, ever, since the contexts are always
fully set by the render functions.
@fix
evas_gl_common_buffer_dump can be used to dump all frames into
a series of PNG files. But the filename contained some garbage
characters (and potential segv, too).
(cherry picked from commit a0f886138ed5a28d0d1596df3b805fca06d1ae31)
It is not necessary to dynamically link to glReadPixels since
this is not an extension. This code wouldn't even work on some
devices.
Also, the pixels returned are not premultiplied (yeah >_<)
And some devices (EGL) don't support GL_BGRA... so glReadPixels
would just fail and not fill in the pixels. Conversion is required.
@bugfix: structure fb_var_screeninfo does not have a colorspace field
defined in linux/fb.h, so (for now) comment out code which was
referencing that field. Not sure what the intent was here, but build
was broken because of this.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
GL_READ_FRAMEBUFFER isn't defined when compiling for Wayland
Thanks Stefan for the report.
Also, import GL_FRAMEBUFFER overrides from other GL files, so
that it points to the proper extension (_OES or _EXT if applicable).
While most framebuffes use stride = width, some may have stride bigger
than width to provide better alignment. Then we must always use stride.
Thanks to Arjan van de Ven, the one that spotted the issue.
@fix
This will be needed by the filters for proxy rendering,
for textures and maps (displacement).
Add new engine functions to unleash the (sluggish) power of glReadPixels.
The idea is to be able to bypass glReadPixels later, so 3 new APIs are
added:
- surface_lock
- surface_read_pixels
- surface_unlock
They must be called in that order.
Note (for history):
glReadPixels was always getting the wrong data during first draw,
but the right data during a redraw...
Why? Well simply because for OpenGL itself, the image had never
been drawn in teh first place! Only the Evas GL context knew
about the image drawing, as it was queued somewhere in the pipe.
One line solution: Call evas_gl_common_context_flush before
doing anything else.
FrameBuffer can be tricky with all combinations and it's hard to tell
users to send useful information, then print the information we use so
we can get useful bug reports.
clean evas_fb_main.c so it returns -1 to indicate invalid fds, same as
open() and what is written in evas_fb.h example.
call fb_cleanup() in all error conditions and always return -1 in
fb_postinit() if we did call fb_cleanup().
@bugfix: Removed hardware acceleration fields from engine structure.
These are now located inside the buffer management code itself, so no
need for them here.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Taekyun Kim
Jean-Philippe Andre
Stefan Schmidt
Carsten Haitzler
Chris Michael
Cedric BAIL
Anand
Jihoon Kim
ChunEon Park
Gustavo Sverzut Barbieri