@bugfix: Set cached image alpha flag properly
This fixes issue where cached image alpha flag was not set properly.
Set it according to the outbuf's destination alpha flag.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: Check (and set) buffer validity before calling
framebuffer_send. This fixes an issue where buffer was not valid,
causing next_update_get to do full Copies.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: We cannot call framebuffer_set from within the send function
because if we are not vsync'd then framebuffer_set would never be
called and thus the buffer would not be marked as valid, causing full
Copies to happen.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: Draw to the front buffer first, instead of the back buffer.
Frenchie says this improves the "initial rendering delay" of expedite
tests. Originally, we were drawing to the back buffer first, then
flipping it onto the crtc when drawing was done. This presented a
"perceived" rendering delay when running expedite tests as it would
wait for the back buffer to be drawn before presenting it. Personally,
I think it is not good to draw directly to the front buffer first as
it may get presented "incomplete" ... but cedric says it draws fine so
we'll leave it starting on the front buffer (for now).
Signed-off-by: Chris Michael <devilhorns@comcast.net>
@feature: Add support for EVAS_DRM_VSYNC environment variable to
@feature: Add support for marking a Framebuffer as dirty.
@bugfix: Fix color mask values for evas conversion functions.
@bugfix: Start with using the Backbuffer for drawing.
@bugfix: Fix previous Slowness with evas_cache image data.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Add ability to render software buffers using vsync or not
@bugfix: Fix drmModeAddFB to use proper depth & bpp when adding FB
@bugfix: Fix mmap to use NULL (not 0) so that kernel assigns memory
address.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@bugfix: this cleans up the Outbuf structure by removing unused
fields, Fixing some function declarations, and defaulting the number
of buffers to 2 (double-buffering)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Start on hardware Plane support
- Add Plane structure
- Store list of Planes in the Output buffer
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- Typically this will come from ecore_evas and be used by evas to
allocate hardware accelerated buffers (gbm, tbm, etc)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@feature: Add code to check if async page flipping is supported by the driver.
@bugfix: Add code to get the proper drm driver name when we init the card.
@bugfix: Use drmOpen when opening the card so that any sub-driver gets initialized.
@bugfix: Add some debug/testing code to enumerate planes.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
updated sooner.
@bugfix: set framebuffer on crtc earlier in process
@bugfix: Set the rendered image's alpha flag to be equal to the output buffer's
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When rotation is 0, we need to advance the destination pointer in the
X direction by a Multiple of Bits-Per-Pixel...not an addition.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When running in direct rendering mode, properly support partial
rendering if the extension is properly supported.
Also, fixed the SwapBufferwWithDamage rectangle coordinate bug.
It wasn't properly y-inverted before.
even though we don't support rectangle bits in texture targets for
texture-from-pixmap the code checked and complained - problem is it
checked the wrong thing. fixes CID 1135267
Summary: Ensure Evas's eglContext when several eglContexts are used.
Test Plan:
1. Native GLES application works with evas_object_image_native_surface_set
2. One Evas object works with evas map.
Reviewers: seoz, tasn, cedric
Reviewed By: cedric
CC: cedric, raster
Differential Revision: https://phab.enlightenment.org/D534
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
Summary: This patch is for QUADRUPLE window buffers.
Test Plan:
When enlightenment uses quadruple buffers or window system can support quadruple buffers,
application can use quadruple buffers with partial rendering
Reviewers: tasn, seoz, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D527
Quick and dirty solution to support the OpenGL engine:
[1] Allocate CPU buffers
[2] Render text and process all effects to these buffers
[3] Push final image as an OpenGL texture.
This patch implements [1].
Summary: Ensure eng_window_use in image_content_hint_set
Test Plan:
1. make native OpenGLES application.
2. set evas object image with evas_object_image_native_surface_set.
3. GLES Application try to call eglMakeCurrent with own eglContext, then resize evas object resize
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D523
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
if alpha4 is possible (desktopgl) then use it for fonts as this should
cut memory in half for them and possibly speed things up due to less
memory bandwidth needed
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
parsing problem with opengl_strtok() which would free the previous
token "p", but in some cases it would be a const string. this should
fix CID 1039653
In my config, running terminology with the GL engine and under
cserve2, some image could not be loaded. The tex argument
in evas_gl_preload_target_[un]register was NULL, leading to
an immediate crash.
When an Ecore_Evas is hidden, it will destroy the buffer swapper. When
it's shown again, it will try to attach a new buffer, that can be same
buffer. If that global var is still pointing to the old buffer, it can
match to it again and avoid sending a new buffer. So, just put this sent
buffer var in the buffer swapper, and it will get set to NULL when the
swapper is destroyed and created again.
This should fix an intermitent problem of ecore_evas_show() not always
working after an ecore_evas_hide() on the wayland_shm engine.
[Problem] When glTextureDelete is called in image_cache_flush(), it sometimes doesn't work.
[Cause] glTextureDelete is called with the wrong eglContext.
[Solution] Call eng_window_use() in image_cache_flush() and image_cache_set() to use the correct eglContext.
Change-Id: Id7ab1aaeb456be6dbc5f09cb2731ace5399a5dce
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
In evas_gl_api_ext_def.h there're calls such as:
_EVASGL_EXT_DRVNAME(EGL_KHR_image_base)
The macro is defined in evas_gl_api_ext.c as:
(strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)
if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;
But EGL_KHR_image_base is itself a macro, which is defined
in EGL/eglext.h like this:
Thus, the _EVASGL_EXT_CHECK_SUPPORT macro will unwrap into:
(strstr(glexts, "1") != NULL || strstr(glueexts, "1") != NULL)
instead of intended:
(strstr(glexts, "EGL_KHR_image_base") != NULL ||
strstr(glueexts, "EGL_KHR_image_base") != NULL)
This patch fixes this by applying stringification earlier in
_EVASGL_EXT_DRVNAME
Bugfix reported by jinhyung.jo@samsung.com
Simply call the appropriate cache2 functions when possible
and check for usage of cache2 whenever an evas_cache_ function
is called.
This effectively adds cserve2 image (data) load support for the
GL engines. Fonts were already working out-of-the-box.
Let's reuse the logic from scalecache and call cserve2
functions when the scalecache should be used.
So, now, cserve2 server will not scale any image... This is
too computationally intensive for the server's main thread.
This is not optimal but makes a hell of a lot more sense for
the moment. (since cserve2 manages the SHM segments)
Pass around "animated" flag for images that can be animated.
Fallback to local cache if the image is animated.
Implementing support for animated images in cserve2 does
not seem to make a lot of sense considering each frame must
be requested independently in real time,... and to be honest
there doesn't seem to be any valid use case anyway :)
cserve2 can't handle virtual files (mmap-only), by design.
Proper support can be added later on, but for now we might want
to just fallback to the normal cache functions.
Fixes photocam test
Evas GL direct rendering mode didn't properly take into account
the image object's clipping information and clip the region that
it was directly rendering to. Hence there were issues with the
direct rendering region drawing over the objects that are sitting
on top of it.
Also, cleaned up the direct rendering coordinate computation code
and a nasty dependency with image object that should have been
removed a long time ago. Basically the evas-gl engine was directly
accessing the image object data structure for its data when it
really should have just passed along necessary information.
For EvasGL direct rendering, EvasGL does a make_current to the
surface that evas is holding on to. When EvasGL was shutting down
it was wrongly deleting evas' surface. This issue was temporarily
fixed by Raphael before but the proper fix was added.
There was already a surface created by _evgl_tls_resource_create(). If
we assign a new one here, the wrong one will be destroyed at
_evgl_tls_resource_destroy(), and later the GL window will be destroyed
before the surface, causing invalid access errors.
This fixes https://phab.enlightenment.org/T326
If the egl_surface is different from the current one, it may be that the
it has been destroyed already. Removing the below check (and just
checking for different contexts) will avoid calling makecurrent when
destroying a window. That was always failing anyway.
Should fix https://phab.enlightenment.org/T311 for gl_x11 too.
If the egl_surface is different from the current one, it may be that the it has
been destroyed already. Removing the below check (and just checking for
different contexts) will avoid calling makecurrent when destroying a window.
That was always failing anyway.
Should fix https://phab.enlightenment.org/T311 for wayland_egl.
At least on recent mesa (since commit 9f07ca11c17), it will find the
mentioned symbols but they won't really work, leading to error messages,
and possibly some other errors. So far, I just ifdef'ed the
glGenFramebuffer and glBindFramebuffer functions, but it may require
others to be ifdef'ed too.
This is just a workaround, to fix https://phab.enlightenment.org/T246.
Chris Michael
Chris Michael
Sung W. Park
Carsten Haitzler
Wonsik Jung
Jean-Philippe Andre
Vostokov Sergey
Daniel Juyung Seo
Dennis Schridde
Rafael Antognolli
Stanislav Vorobiov
Cedric Bail
Sebastian Dransfeld
Sung W. Park