This reverts commit 60b473d949.
It breaks our mingw cross build setup we are using on jenkins. In summary it
silently fails to use eolian_gen.exe while it should use the linux native
eolian_gen and thus does not generate the c and h files from the eo ones.
See the ml for details or look at the error here:
https://build.enlightenment.org/job/changely_efl_mingw_x86_64/2115/console
Before this patch, those EGL/EvasGL functions can not work
without a current context. But EGL does not require any
current context for those to work, or at least, this should
be left to the driver to decide.
Evas GL was only able to get a pointer to the display
if a context was current.
The display pointer should be infered from Evas_GL unless
we can find a current display. EGL does not require a
context to be current in most of these function calls.
This should bring evasgl a little bit closer to EGL in terms
of behaviour (those are EGL-only extensions, btw).
Thanks @spacegrapher for the quick review
@fix
Summary:
Now Evas gl preload feature is disabled.
But if it is turned on, memory crash occurs.
Because evas_gl_common_texture_upload is not excuted immediately.
Test Plan: EVAS_GL_PRELOAD=1 ELM_ENGINE=gl elementary_test -to "photocam"
Reviewers: raster, cedric, woohyun, seoz, Hermet, singh.amitesh, jpeg
Subscribers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D2823
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
When glClear is called in direct rendering move (DR), we usually
have to skip the call altogether because clearing out transparency
would erase the pixels in the evas backbuffer. This means Evas
would not be able to blend an RGBA GLView on top of other objects.
But COPY mode should allow Evas GL to poke holes in a window
backbuffer.
Thanks @spacegrapher for the review :)
NOTE: Elm GLView also needs to pass the render op to its Evas.Image.
@fix
evas_gl_native_context_get is an internal function
passed around from an evas engine to evas_gl so that we can
implement evasglCreateImageForContext without exposing
any evas engine internal structure to evas_gl.
It's all a ittle bit ugly but the previous solution with
dlsym(DEFAULT) didn't work.
Failing to load a module that does not exist is indeed not an error,
but failing to load a module that exists on disk happened probably
because of an error like "symbol not found".
Considering eina_module is most likely used by EFL itself, I believe
an internal linking failure is a warning worth reporting.
If the TLS variable was not initialized, Evas GL can't get a pointer
to a valid EGLDisplay which is required by eglImageDestroy.
So, we keep track of the dpy used at creation time and use that
if we're in another thread.
Summary:
Apart from evas_canvas3d_node_look_at_set() all other things are referenced.
Tried to reference it to @Evas.Canvas3D.Node.look_at_set(). But getting error.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, tasn, q66
Reviewed By: q66
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2822
This reverts commit 5beb47aa4d.
Revert "image_savers/jpeg: fix undefined behavior of using sigsetjmp on jmp_buf"
This reverts commit 84c7751e19.
these end up with efl simply not compiling. efl tree does not build at
all now and this warrants a revert.
lib/evas/.libs/libevas.so: undefined reference to sigjmp'
collect2: error: ld returned 1 exit status
Makefile:19321: recipe for target 'bin/evas/evas_cserve2' failed
.. etc.