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.