do it once and remember the result from the first one. drops overhead
for sure by a chunk i actually could see in perf reports like about 1-2%
of cpu...
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 ;)
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
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...
Summary:
Evas Image should be independent of render engine.
So remove native.func.data member of RGBA_Image, Evas_GL_Image struct.
And remove data argument,too.
Test Plan: Local test, Tizen3.0 mobile, Desktop englitenment
Reviewers: jpeg, spacegrapher, wonsik
Subscribers: cedric, dkdk
Differential Revision: https://phab.enlightenment.org/D3850
Summary:
'cached' flag is not enough to check whethere data is loaded and texture is uploaded.
so check more options for prevent re-preload image data on gl-backend.
Test Plan: Local Test (elementary_test : elm images)
Reviewers: jpeg, eunue
Reviewed By: jpeg
Subscribers: cedric, jiin.moon, wonsik, spacegrapher
Differential Revision: https://phab.enlightenment.org/D3446
egl images created using tbm surface for native surface set use
GL_TEXTURE_EXTERNAL_OES as texture target, so we should bind to
this target when rendering.
Dynamic hint set using tbm surface also creates egl images, but
as we only use RGB* colorspace for this we can use GL_TEXTURE_2D.
So, keep track of texture target in shader array, and bind to the
appropriate one.
This also fixes the bug that image_data_get only worked when BOTH
sec_image_map and sec_tbm_surface extensions are supported.
this fixes rendering on ppc (bigendian) where we have thnigs swizzled
oddly. not bgra -> argb but rgba -> grab ...
so generate a bigendian shader file and use if on bigendian.
this should fix T2721
it fixes it in the visual screenshots i can get remotely.
Evas_GL_Image created for font glyphs in evas_common_font_rgba_draw
is sometimes freed after Evas_Engine_GL_Context is freed.
Since gc is already freed, pt_unref returns and leaves pt behind.
evas gl common was simply resetting to the wrong texture id in the gl
context struct - it was using pipe[0] not state.current. why i don't
know. i know i wrote the pipe[0] code many years ago - really don';t
know. it may have been a transitional piece of code that just happened
t6o work 99% of the time that never got fixe when i added pipes.
@fix
this pulls yuv in line with yuy2 textures and dobule buffers them.
this is a workaround some driver bugs where either the driver doesnt
block and wait for the gpu to finish with a texture when updating OR
it does wait, and when it does it blocks and spins using cpu.
Summary:
Set size of texture unit without 2 pixels for borders in case use it without
atlses. Just one case if texture for 3D use repeat mode and non-normalized
tuxture coordinates
Reviewers: Hermet, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2805
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
if yuou use 709 instead of 601 yuv (ycbcr) evas will just be wrong and
use 601. this fixes that and implements 709. it also fixes a scaling
bug for yuv in the gl engine. no one noticed but me, so i won't call
this a bug fix, and it can go into the next efl release - no need to
backport unless it actually bothers peolpe (which it seemingly doesn't)
Summary:
It is need in case Evas_3D_Mesh created with not normileze texture coordinate
and flag repeat mode for Evas_3D_Texture
Additional info see here https://phab.enlightenment.org/conpherence/54/
Use Evas_GL_Image for generation texture unit for Evas_3D_Texture
see here https://phab.enlightenment.org/D2371
Reviewers: jpeg, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2375
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The pixel on the top-right of a texture was set using an invalid offset.
"luckily" this never crashed but probably could have with wide
single-row images.
Also, the output was not perfectly correct.
Unfortunately, this "feature" has many problems and does not really
fix those it was supposed to address:
- Elm Photocam becomes horrible to use (the transition from
low-res to high-res tiles triggers this miniature path).
- Evas async preload callback is called before the full image
is ready (ie. the texture is not uploaded yet), when really
the preload callback should be triggered only once the image
is 100% ready. (TODO)
- Sometimes the miniature image keeps being used even though the
main image has been uploaded (eg. with E background). Maybe the
object image is not redrawn when it should.
- This uses a separate thread for the upload, which is both a good
and bad idea because we need to do a make current. Also, this does
not upload the full-res image tile by tile, but only in one pass,
thus blocking the render loop until finished.
This patch changes the env var from "EVAS_GL_NOPRELOAD" to
"EVAS_GL_PRELOAD" (and only "1" will enable).
Sorry Cedric, we can talk later about how to improve this.
Sample in the middle of the "macro pixels" and fool around with the
borders (usually used to limit linear sampling artifacts) to improve
image quality on the edges.
Those miniatures are still 16x16 but MAAAYYYYYBE they will look a bit
less awful.
NOTE: The first row still doesn't scale properly (interpolates with
garbage above y=0).
Summary:
Currently dynamic hint set is implemented using eglMapImageSEC extension,
which is no longer supported by any drivers (should be deprecated)
This patch implements dynamic hint set using Khronos extension EGL_TIZEN_image_native_surface.
Since tbm surface library is required for this, libtbm.so is queried at context new.
Test Plan: Local tests
Reviewers: raster, Hermet, cedric, jpeg
Subscribers: mer.kim, wonsik, cedric
Differential Revision: https://phab.enlightenment.org/D2027
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
jpeg: I also fixed a few minor style issues and two warnings (bad function
names, glsym instead of secsym).
The exact same ugly macro would appear hundreds of times in the GL
code:
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
Instead, override the common GL functions iif GL_ERRORS is defined.
This greatly simplifies code and removes tons of useless lines.
Also, this will give better debugging output as the exact code line
is printed, and the function name is also printed.
Also, fix linking to the glerr function.
This is a code cleanup. Hopefully I didn't break anything with this
big operation of find & replace.
This fix T1459. I have added an ERR to catch this kind of issue earlier.
I am wondering if that should not be even a CRI.
The reason why we do see the problem only after the introduction of the
use of Eina_Rectangle_Pool is due to how efficiently they pack data, resulting
in ressource ending up in the wrong format bucket. Nothing wrong with the
patch itself.
We cannot use the texture to find a valid format Before the texture is
actually created. This is invalid, leads to "warning: tex is used
uninitialized' message from the compiler, and just plain wrong.
Instead, use the alpha property of the Evas_GL_Image to find the
proper texture format, Then create the texture.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so in fixing one CID for a format lookup failing and thus invalid mem
access, a possible leak was made in this case. fix that by doing
lookup before any allocation and if lookup fails, return there
this fixes CID 1230999 1230998 1230997
Eeeeh. Not only we don't support atlasses with this RGB+A thing
yet, but ETC1 does not even support SubImage2D (according to the
current spec).
Also, fix a few typos in that same function.
Some colorspaces (ETC, S3TC, GRY, ...) don't care about the value
of BGRA support or the alpha flag. So, let's introduce the
new boolean^Wenum value MATCH_ANY ;)
Note: the compressed texture formats with alpha support have been
marked as matching both TRUE and FALSE for alpha. The images
should always have the alpha flag set to TRUE, though.
The BGRA flag really doesn't matter.
Elyes HAOUAS
Vincent Torri
Carsten Haitzler
Chris Michael
Jean-Philippe Andre
Derek Foreman
Subhransu Mohanty
Minkyoung Kim
Mike Blumenkrantz
Dongyeon Kim
Oleksandr Shcherbina
WooHyun Jung
Ji-Youn Park
Daniel Zaoui
Cedric Bail
Stefan Schmidt