Set this env var to "300 es" to test GLSL 300 ES as shader
version. This is for brokenshakles.
Example:
export EVAS_GL_GET_PROGRAM_BINARY=0
export EVAS_GL_SHADER_GLSL_VERSION="300 es"
export ELM_ACCEL=gl
elementary_test
Removes the previous "busy" flag, as now we might have an fb attached to
multiple outputs at once, and need to be careful to destroy them only
after they've been removed from all outputs.
Removed the old "busy_set" API which nothing used, and renames fb_destroy
to fb_discard to make it more clear that it's not immediately destroyed.
It's all beta api, so I can do this.
Omg... Thanks Daekwang Ryu for pointing me to my error. I remember
struggling a lot with this OpenGL API and libGLdispatch (glvnd) when
in fact this was all just a typo in the code.
GLES 3.1 and the upcoming 3.2 support need a proper test case...
See c68a409874
@fix
Somehow this long standing bug wasn't obvious until wayland 1.13.0 made
some additions to an opaque structure.
This changed the frequency that new buffers came to us with the exact
same pointer value of a buffer that had just been freed.
This shortcut in eng_image_native_set has always been wrong - we need to
proceed to the end to make sure we pick up new dmabuf attributes.
Summary:
Evas can't open tiff file because of no implement in client read api.
I wrote codes simply for open.
Test Plan: self
Reviewers: jpeg, cedric, jypark
Subscribers: stefan_schmidt
Differential Revision: https://phab.enlightenment.org/D4857
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
This might not be used as over two consecutive runs all the
same buffers should be used. But it could happen if some
parameters in the filter change (eg. blur radius).
Fixes major (GPU) memory leaks. Reuse mode is still leaking.
An odd-sized image scaled down by 2 was losing 1 pixel during the
downscale, and it was not restored after scaling up. The same
happened with downscaling by 4 except the effect was even more
visible.
This meant that a moving snapshot with a large blur would trigger
some really ugly sampling issues if the content below was precise
(such a text).
This dramatically improves the performance and now seems
to give acceptable results. Eventually we need a quality flag
in order to enable this or not. Alternatively, "gaussian" blur
mode would skip this optimization, while "default" would trigger
it.
This can help with performance when a large region of the
filtered image (eg. snapshot) is fully hidden by an opaque
object. For instance the window border is hidden by the
opaque window content.
This make save() work on snapshot objects, provided the call
is done from inside render_post.
Also, this saves the filtered output of an image, rather than
its source pixels. Any call to save() on a filtered image must
be done from post-render as well.
Fixes T2102
@feature
If we delete the image that was the target surface for gl
rendering, a crash would occur on the next render cycle.
Unlikely but not impossible to trigger from app side.
@fix
This was a poor attempt at improving the performance but
obviously the root cause isn't fixed (too many texel fetches).
Uniform should (theoretically) work better than an attribute
the for loop. Just a guess here.
This also makes GL blur use a float value as radius, allowing
future extension to non-integer blur radii, as well as using
linear scaling as a fast blur approximation.
This optimizes the GL blur algorithm by reducing the number of
texel fetches (roughly half the number of before this patch). This
works by exploiting GL's interpolation capabilities.
By simply splitting X and Y blurs in two passes we can improve
the performance of the blur filter a lot.
There is still much to be done to make it really fast and nice
looking:
- implement true gaussian blur (not sine-based approximation,
right now the actual blurs look different in SW and GL)
- exploit linear interpolation for R tap instead of R*2+1 taps
(a tap being a texel fetch)
- downscale & upscale large images with large blur radii
Wait a second though, this implementation is not only incomplete
(no support for box vs. gaussian blur), it's also insanely bad in
terms of performance. Small radii may work fine, but at least blurs
render properly in GL with this patch (no more glReadPixels!).
The shader needs a lot of love, including in particular:
- support for 1D box blur single pass
- support for 1D gaussian (or sine) blur
- use linear interpolation and N-tap filters
- separation of 2D blur in two passes (high-level logic)
- potentially separation of large 1D blurs in 2 or more passes
knowing that 2sigma == sigma + sigma when it comes to the gaussian
bell curve.
This one was a bit more... "fun". I had to add a new vertex
attribute and obviously using a VertexAttribPointer led to
incomprehensible crashes. But a simple glVertexAttrib2fv makes
it work like a charm!
A rare option is not handled yet.
This reuses the existing mask infrastructure, but adds a color
flag to use the whole RGBA range, rather than just the Alpha
channel.
Filters are still very slow (glReadPixels and non-optimized use of
GL buffers...), but this is progress :)
This corrects two things:
- the blur filter high-level logic, that lead to reusing some
temporary buffers which contained garbage;
- the versatile gl buffer implementation so that it now properly
switches between the RGBA_Image and the FBO content (yes, this
is insanely slow and inefficient... but it works and that was
the only point).
Alright, so this is a massive patch that is the result of
trying to get rid of unused or poorly implemented classes in
ector. Originally ector was meant to support VG but extend to
things like filters as well. At the moment, ector's design
makes it quite hard to plug in the filters.
For now I think it's easier to implement the GL support for
the filters directly in the engine, where I hope to interfere
as little as possible.
This massive patch keeps only the required minimum to support
a versatile gl buffer that can be mapped, drawn or rendered to (FBO).
It's extremely inefficient as it relies on glReadPixels and lots
of texture uploads, as well as conversions between ARGB and Alpha.
Another type of GL buffer is a wrap around an existing GL image,
but that one is read-only (map or draw: no write map, no FBO).
No, all the filters run fine, and the high-level implementation
(evas_filters.c) does not need to know whether the underlying engine
is SW or GL. One problem though appears with the blending or blurring
of some Alpha buffers, the colors are wrong.
This patch removes more lines than it adds so it must be good ;)
This is an attempt at refactoring the filters code so I can
later implement GL support. This patch adds a few extra changes
to remove avoid calling functions of libevas from the software
engine: use the draw functions from static_libs/draw rather
than evas_common APIs.
Summary:
Before, rsc->current_ctx is always same with ctx.
So checking context change was meaningless.
From now, it has meaning.
Test Plan: App call evas_gl_make_current more than twice in pixels callback. Those surfaces are indirect rendering surface.
Reviewers: jpeg, dkdk, wonsik
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4773
Summary:
If the last item before ellipsis item has bigger width than its advance,
evas_common_font_query_last_up_to_pos() function can find wrong ellipsis position.
When Evas finds a position for non last item, Evas must care about additionally
available space for glyph's width of the given x position.
ex) the last item's glyph before ellipsis item has a tail to draw above the ellipsis item.
@fix
Test Plan:
Test case will added as comment.
(Becasue of font license problem.)
Reviewers: herdsman, raster, jpeg, woohyun
Subscribers: cedric, Blackmole
Differential Revision: https://phab.enlightenment.org/D4727
The things you learn to love...
The situation was:
- An object is mapped (naviframe in an animation)
- One of its children has a mask
- The window is rotated by 90 or 270 degrees (landscape)
The mask glsl code to invert the x,y coordinate depends on the
screen rotation and this somehow was wrong.
Tested on Tizen and in elm_test "Masking", made with @jiin.moon.
@fix
If we don't have EGL_EXT_buffer_age then we don't have buffer age - it's
a completely independent extension to KHR partial update.
This partially fixes partial update on recent mali drivers.
I believe there's a limitation in libglvnd where it doesn't
propagate the calls to eglGetProcAddress() properly to the vendor
library.
See also 265c851a8f
It seems OSMesa was recently updated to not expose symbols statically,
so dlsym() returns invariably NULL. GetProcAddress must be used. Note
though that the extension "EGL_KHR_get_all_proc_addresses" is not
present (OSMesa is OpenGL, not GLES), and there is anyway no list
of extensions in OSMesa (at the WSI level, glGetString() returns a
ton of GL extensions as expected).
My OSMesa version is 11.2.0 (mesa 17.0.1).
This fixes make check.
@fix
If GL context is free'd before processing font shutdown,
textures for emoji glyph's GL images will be free'd without clean
up its GL images. It causes eina mempool infinite loop issue when
emoji's GL images are free'd in shutdown process.
So, the patch will make a list for emoji's GL images in context and
clean up them when the context is free'd. Just like font textures in
context.
@fix
Differential Revision: https://phab.enlightenment.org/D4695
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
It was assumed that GLES 3 would only work with EGL but in fact
OpenGL 4.3 & 4.5 are supersets of GLES 3.0 & 3.1 respectively. So
GLX should also support GLES 3.0 or GLES 3.1 for evas gl, if the
driver supports it, of course.
Of course while doing this patch things didn't go like they were
supposed to go. I'm currently using NVIDIA's proprietary driver,
that conveniently provides EGL with GLES 3.2. But wait, there's
a catch: GL_VERSION is "OpenGL ES 3.2 NVIDIA" except that none
of the functions of GLES 3.1 or GLES 3.2 are actually supported.
Those functions are only present in the GLX/OpenGL variant of the
driver. Thanks so much for making my life easier...
So yeah, this patch contains a hack for those invalid versions
of GLES 3.x. What was supposed to be a small fix became a huge
mess.
Also add a comment about the possibly invalid auto-upgrade from
GLES 2 to GLES 3.
This adds a test case in elm_test, but only to verify that
elm_glview_version_add(3) actually works. We need a proper GLES 3
test case, eventually (and 3.1, 3.2 of course).
I believe that all the threads created in our test suite should
be spawned without any special CPU affinity. The default parameter
is not 0 (corresponds to the first CPU, known as CPU 0) but -1.
Similarily the default priority is NORMAL (1), not 0 (URGENT).
This also affects two unused code paths: evas render2 and gl preload.
@fix
When wayland session recovery happens, we can end up down this path
with no gl context when elm reprocesses its config file.
That callback fires long before we've re-set up our wayland connection
so we can't possibly have a valid gl context yet.
Prevent that from crashing.
This should fix an ERR message under gl_drm and probably an
actual bug.
This reverts 8f2cfdf490.
I don't think the texture target should be part of the context
information. It should instead be a property of the texture.
Fixes T5171
See b16c961680 which by "fixing" indentation changed the
logic of the code. Yes the indentation was misleading (because of
the #if / #else) but the logic was correct. Anyway this is was not
a harmful issue as those memory trackers aren't really used.
gcc reports that the 'else' here does not guard the latter
statement...seems like a cause of some missing parens so fix.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
MSAA (multisampled_render_to_texture) support was implemented with
GLES 2 in mind, but for GLES 3 it comes as a core feature, not as
an extension. Also it relies on renderbuffers, not textures. GL
is awesome.
Note: MSAA still doesn't work!
Summary:
glFramebufferTexture2DMultisampleEXT() supports color attachment only.
so depth&stencil attachment should be bound via renderbuffer not texture.
According to http://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt
In order to allow the use of multisampled depth and stencil buffers
when performing multisampled rendering to a texture, the extension
also adds the command RenderbufferStorageMultisampleEXT.
target, textarget, texture, and level correspond to the same
parameters for FramebufferTexture2D and have the same restrictions.
attachment must be COLOR_ATTACHMENT0.
Test Plan: Evas GL on GLES 3
Reviewers: jpeg, raster, dkdk, wonsik
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D4648
gif's logical screen size (which is considered the image size)
might be different from the size of each frame.
when decoding a frame, the width and height of the decoded data should be
based on the size of the frame, not on the size of the logical screen size.
if a frame is decoded into a buffer of screen size, this might happen
(frame = 6 X 3, logical screen = 5 X 3)
OOOXXX OOOXX
OOOXXX => XOOOX
OOOXXX XXOOO
@fix
this struct is not actually used other than in this func ptr decl and
it's warning-land for gcc, so .. make it void * and do things like
pretty much all other gl extn func ptrs... be very generic
this struct is not actually used other than in this func ptr decl and
it's warning-land for gcc, so .. make it void * and do things like
pretty much all other gl extn func ptrs... be very generic
since these are only local path resolves, the do and wait are
technically not needed. also remove any other tmp strings
and use the vpath string resolving feature to avoid
printfs/strjoins/cats etc. etc. as well.
also remember to remove old name string from evas shm code - it worked
for me. i guess i was lucky and it happened to be NULL thus free was
fine.
This reverts commit 2037474dc0.
This causes the wayland_shm engine to seg fault immediately at
startup when attempting to create shm buffers.
Please make sure when committing changes to the wayland_shm engine to
test on intel, exynos, and at least one platform without dmabuf
capabilities - or using the EVAS_WAYLAND_SHM_DISABLE_DMABUF env var
to disable dmabuf on intel or exynos.
Anyone without the time or hardware to fully test changes to wayland_shm
can submit a patch to phabricator and assign it to me so I can fully
test it before landing.
since these are only local path resolves, the do and wait are
technically not needed. also remove any other tmp strings and use the
vpath string resolving feature to avoid printfs/strjoins/cats etc.
etc. as well.
this allows only /dev/fb[0-0] or /dev/fb/something where somthing does
not begin with a . - thus no way to break out of the fb subdir... so
it should be ok... this keeps setuid safety and allows this env var to
work now as intended in this situation.
this should make the wayland shm engine safe to use from setuid
processes. it shouldnt depend on getenv of specific file paths if
setuid. vpatrh takes care of this in one central place
newframe() resets some of the gl context properties, so match them
to our shadow copy in the gc state.
target_surface_set() also resets some of those properties but only
in our shadow copy, not in the actual GL context. As a consequence
we can't rely on setting a bool to 0 or 1 unless we also call the
equivalent GL function. Expand bitfields to 2 bits allows us to
set a bool to the invalid value of -1 (yes, that's not a real bool).
Also there is no need to reset the target surface to NULL during
newframe. It will be reset during target_surface_set.
This fixes some issues I encounter while working on GL filters.
we use invalid values (-1 or 0xff or 0x3 etc. invalid vals to know to reset
some state). expand fields out in size a little bit to allow that to
work again.
this reduced pipes to 32 as default max pipes is 32 and we never
actually go up beyond 32 unless oyu use env vars to expand... and no
one will... and actual testing shows us top out at about 30 pipes
usage in anything i can find/test. this packs more bool flags together
as bits instead of itns or chars to save memory.
@optimize
this improves performance a bit by avoding libc's malloc and the heap
by using a custom buffer pool thathas basically immediate O(1) lookup
time (in real life) that baloons out and contracts back as time goes on.
@optimize
Small patch to compare if the hidden flag being passed in is the same
as the one stored in Outbuf. With the addition of xdg_shell v6
support, we cannot commit a surface with an existing buffer until the
surface has been configured. In order to facilitate this, we will use
the 'hidden' flag so that any surface_post does not actually attach a
buffer unless configure has already been handled on the surface.
ref T5090
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports this as in incorrect expression because it was
checking cache_entry width <= 0 twice. Fairly safe to assume that the
proper check should be width || height.
Fix CID1368336
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so i had a crash where my bt said the image size is 1x1 but the img
struct said its 0x0, so put in protection to not upload a texture from
a 0x0 image... just for now... because this is odd - the image data is
a real ptr i can access and there should be at least 1 pixel... but i
can't be sure this fixes it as this is one of those "one offs" i cant
reproduce...
@fix
On session recovery the engine needs to be given new copies of the
surface, dmabuf, and shm objects to run in the new connection.
This fixes session recovery breakage introduced when we stopped recreating
the outbuf on reconfigure.
so removing eglSwapInterval() is a very poor idea as then... who knwos
what it is? this broke at least nouveau (under weston AND under
enlightenment). a very skillful b0rk here than i luckily caught
quickly! :)
We have some "vsync" variable cargo culted from somewhere that is never
properly set, so is always 0 because it's in a calloced structure.
It's then used to set eglSwapInterval() to 0 always, which results
in mesa using wl_display_sync() instead of wl_surface_frame() for
its frame ready callback mechanism.
Remove it entirely and use the sensible default swapinterval.
This keeps us from accidentally going through the fallback path twice and
crashing. It also clears up some refcounting problems that would have led
to leaked memory in the crash case.
fix T5037
so we had just 128 bytes for path to generic loader utility. in most
cases this is plenty but if you have bizarre symlinks and long paths
we may run out of space, so move up to 4k buffers as this is
realistically the max path len anyway on a system.
@fix
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
i found evas_common_draw_context_apply_cutouts() was procsessing 300+
cutouts and as it's O(n^2)/2 to try and merge adjacent rects for
cutouts this really performs like complete junk. we apply cutout rects
a LOT. this is not the best solution, but it's quick and much faster
than doing the clipouts which drop framerate to like 1-2fps or so in the
nasty case i say (tyls -m of photos in a dir with a 2160 high
terminal).
this figures out the target area to limit the count of rects
significantly so O(n^2) is far far better when n is now < 10 most of
the time. and for the few operations where it's a high value this now
uses qsort to speed up merges etc. etc.
@optimize
Summary:
If user bind textureA and want to use it continuously, do not call glBindTexture(textureA) again.
But expect that textureA will be binding.
So EvasGL sould not change binded texture silently.
Restore texture to previous bound one after allocating new texture.
And when destroy texture, reset texture to 0 if it is current bound texture.
Test Plan: Tizen 3.0
Reviewers: wonsik, dkdk, cedric, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D4524
This enables the PNG saver to save images with gray and
alpha + gray colorspaces. GRY8 is usually used for alpha only.
Note: This commit also introduces whitespace changes. Sorry
about the mess, but at least now we have spaces only. Read the
commit with show -w :)
@feature
This fixes evas_object_image_save after changing the orientation
of an image in the GL engine. In SW engine the pixel data is rotated
in memory, so things worked fine from the beginning. In GL we may
have to go through loops and hoops in order to rotate and fetch the
data from the GL texture.
This should fix ce45d44.
If someone's trying to build efl git with 2.5 year old EGL headers they get
a break on missing EGLImage...
We should probably consider keeping an up to date copy of the EGL headers
in efl. There may be someone out there with even older headers.
As suggested by @k-s
I'm pretty sure that this parser will easily fail. Eg. find uchar
properties but it's not r,g,b in this exact order? No color for you.
Find no uchar at all? Fail immediately even if we can handle a
no color situation just fine.
There's actually an array of 2 in gl_x11, but it appears we only use the
first 1, except in an #if 0 block.
I gather this is legacy for some reason - it sure doesn't seem to make
any sense now, so I'm chopping off all the extra array indexes.
Note: I've not changed gl_sdl - it looks like it doesn't use the context
or surface at all and they could just be removed, but I don't build that
one here and don't want to touch it.
This patch just removes the 'evas' field from the Outbuf structure.
This should have actually gone in on the previous patch but I missed
removing it :(
Signed-off-by: Chris Michael <cp.michael@samsung.com>
These variables are unused (as reported by gcc), and 'ob' is not
really needed in eng_update so remove that also.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
A previous patch to refactor setup stage and reduce complexity
actually introduced several build breaks. This patch fixes the build
break for wayland-egl.
ref 73b308fb66
BAD CEDRIC !!!!!
Signed-off-by: Chris Michael <cp.michael@samsung.com>
A previous patch from some french guy broke building of the gl_drm
engine. This patch fixes the build break and cleans up unused
variables, etc.
ref 73b308fb66
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Seems Cedric's patch for refactoring setup stage broke building for
the evas drm engine. This patches fixes the issue.
ref 73b308fb66
Signed-off-by: Chris Michael <cp.michael@samsung.com>
eglGetProcAddress should be queried with dlsym unconditionally. What we
had could query it with other extended forms of eglGetProcAddress, which
is probably not what anyone wants.
Also, throwing away the weird extended forms because there's a good chance
our other gl bits don't run on any stacks that don't support normal
eglGetProcAddress.
Commit fcef8d8392
breaks any evas engine that frees/NULLs its own outbuf before
calling evas_render_engine_software_generic_update()
We should unconditionally set the outbuf, we only need to
do the free conditionally.
evas_render_engine_software_generic_update(0 definitely is wrong where
it wants to always free the outbuf even if the buffer passed in is the
same one and thus it ends up being freed and now invalid. fix it
@fix
Because we async render into buffers before the compositor has told us
we can use them, we can end up kicking over to fallback while still
rendering into a buffer.
Refcount the manager to let us clean up properly without crashing when
this happens.
If we render fast enough we can use more than one buffer before the
compositor assigns us buffer ids. We need to be careful to clear the
busy bit on all but the most recent one.
Enlightenment needs to know if a specific dmabuf format is supported
before it lets clients use it. This lets E test commit a wayland
dmabuf object without assigning it a buffer.
Previous patch to not destroy Outbuf on resize should not have removed
this line else software generic tilebuffers will not be in sync with
the updated size.
ref 5ebba4463
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This line should not have been removed from the previous patch. Thanks
to Cedric for catching this.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
On an engine resize, we previously would destroy the Outbuf structure.
This patch modifies the code so that on a resize we no longer have to
destroy the old Outbuf and reallocate a new one. Instead, we will just
reconfigure the existing one and update it's properties.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
On an engine resize, rather than destroy & recreate the Outbuf
structure (and the associated surface) we can just call the
eng_output_resize function (which in turn will call
outbuf_reconfigure) to update Outbuf with new properties. This saves
us from having to create a whole new Outbuf every time we resize.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
Using *im and dereferencing it before doing the actual NULL check does not make
much sense. I kept the checks as they have been there before so the intent was
probably that they could be NULL and should be checked.
CID: 1270030, 1270029, 1270028
If the hidden flag is set, then we don't need to recreate the Outbuf
for a given canvas as the window is hidden and we are not going to
render there until it's shown again.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When a canvas gets hidden, we don't need to destroy & recreate the
wl_surface. We can simply attach a NULL wl_buffer to the surface which
achieves the same result. This saves us from having to always destroy
& recreate surfaces when we hide/show.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Software rendered wayland clients will now attempt
to use dmabuf on some platforms. This results in a window
that a compositor may be able to drop into a plane without a copy.
Disable it with the env var EVAS_WAYLAND_SHM_DISABLE_DMABUF
but if you need to disable it, please ping me or file a bug report.
Thank you NVIDIA for breaking your drivers regularly!
eglGetDisplay(x11_display) should work but was consistently
returning 0 instead.
Apparently EGL 1.5 introduced "eglGetPlatformDisplay" that
is more advanced to open a display. So, prefer that over
eglGetDisplay if it's available.
@fix
when the DIB header is BITMAPINFOHEADER (size 40),
a bitmap file has alpha channel only if the compression method is BI_ALPHABITFIELDS (= 6).
the original code enabled alpha channel when the compression method was BI_RGB (= 0),
which made an opaque bmp image loaded as a transparent one.
@fix
Not providing a call to the first method segfaults in elm_glview
right away. Instead of crashing, we now just issue a runtime error
about the method not being implemented.
If there's a "next" buffer set, we're better off freeing it before we
start to render. This lets us keep gbm from allocating an extra buffer
which it currently never frees.
Previously we'd call this only when we absolutely needed to, so it made
sense to always attempt to free a buffer, including ones on scanout or
pending flip.
However, it's useful to have a way to release the "next" only, so we can
do that before starting a render to free up the buffer that's never going
to be scanned out.
for gl noscale buffers are texture atlases that are fbo's. the point
is never to scale or transofmr them but to render them pixel for pixel
and just store pre-rendered data where its cheaper to do this than
rebuild every time. this is the enigne infra for sw and gl with the gl
code... it SHOULD work... in theory...
preparing an object is a good idea. especially with gl. you want to do
texture uploads BEFORE using textures all in one batch. otherwise this
may mean the gl implementation has to make a copy of your data in a
tmp location then copy it in later when texture becomes "unused" as it
may be in use at the moment, or it may have to stall and wait.
i have seen somewhere around 7-10% speedups on nvidia and intel
drivers with this on given a very special test case i brewed up (1000
32x32 images where i change 1 pixel every frame). this should have
impact really when we are modifying textures a lot. this is all i've
implemented for now, but this should/would/could do much more like
re-order map, proxy renders to render FIRST in a pre-render list
instead of inline and to pre-render fbo/buffer content for complex
objects like text or textblock etc.
this will define EGL_WAYLAND_PLANE_WL and EGL_WAYLAND_BUFFER_WL if
missing as SOME older egl public headers dont expose them and yet we
still wans to compile and support the feature should the egl BINARY
etc. actually support this (or be upgraded to support it after efl
compilation).
@fix
this technically isn't needed. it does help in some cases hide driver
or other buffer swap bugs, but in and of itself is not needed, so
remove. at least the drm egl bugs still happen on my pi3 so its
something else...
Cedric BAIL
Jean-Philippe Andre
Derek Foreman
jiin.moon
Stefan Schmidt
Carsten Haitzler
Minkyoung Kim
Youngbok Shin
Jean Guyomarc'h
Godly T.Alias
Chris Michael
Jaeun Choi
Daniel Kolesa
Awadhesh Singh
Andrii Kroitor
Subhransu Mohanty