summaryrefslogtreecommitdiff
path: root/src/modules/evas/engines/software_generic/evas_ector_software_buffer.c (follow)
AgeCommit message (Collapse)Author
2018-02-08ector: Updated the ector_buffer_pixels_set() api with stride infosubhransu mohanty
Reviewers: jypark, jpeg Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D5795
2017-08-16evas: Fix crash with filtersJean-Philippe Andre
Since the EO APIs are defined as weak symbols, invalid definitions of EAPI lead to runtime crashes on non-public APIs. This is a fix following a series of changes wrt. EAPI definitions.
2017-04-25evas: do not rely on Evas canvas for Evas Ector engine backend.Cedric BAIL
2017-04-14evas filters: Fix blur logic and GL buffer handlingJean-Philippe Andre
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).
2017-04-14evas filters: Refactor ector and gfx filters A LOTJean-Philippe Andre
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 ;)
2016-10-06evas: Fix async filters following changes in EOJean-Philippe Andre
EO is now extremely restrictive wrt. threads so that efl_data_scope_get() can't work outside the main loop. This patch fixes the usage to create sw buffers as shared objects (accessible from both the main loop and evas async thread) and use plain old pointers where possible. The buffers now have no parent because efl_add(CLASS, obj_from_mainloop) does not work with shared objects. This is bad, as the buffers conceptually belong to the main loop, and only need to be accessible from the draw thread for a few calls. The main loop determines their lifecycle. Fixes T4628
2016-08-15Eo: Finish the renaming of Eo to the EFL.Tom Hacohen
This renames all the rest of the API to the EFL namespace except for Eo_Event that will follow soon. Obviously breaks both API and ABI.
2016-08-11Change the EFL to follow the new Eo rename.Tom Hacohen
2016-07-24ector module - remove sueless chekc for null done already CID 1347411Carsten Haitzler (Rasterman)
fixes a pointeless check coverity found
2016-03-03Fix migration script mistakes and compilation warnings.Tom Hacohen
Mostly unused vars following the removal of eo_do_ret(). However, there are some cases where the migration script got some things wrong, and I had to manually fix them.
2016-03-03Automatic migration to Eo4.Tom Hacohen
I just ran my script (email to follow) to migrate all of the EFL automatically. This commit is *only* the automatic conversion, so it can be easily reverted and re-run.
2016-01-05Evas filters & Ector GL: Prepare ground work for GL buffersJean-Philippe Andre
This fixes crashes, adds safety, and notes a couple of things that are not yet implemented: - Make an Evas_GL_Image from an RGBA_Image so we can draw it on the canvas. This means Evas.Ector.GL.RGBA_Image.Buffer - Readable Evas_GL_Image objects with gl_read_pixels --> Implement proper map() & unmap() for GL buffers
2016-01-05Ector GL: Add skeletton for Evas.Ector.GL.Image.BufferJean-Philippe Andre
This is an ector buffer backed by an existing Evas_GL_Image
2016-01-05Evas filters: Use Ector.Buffer instead of RGBA_ImageJean-Philippe Andre
This is a major refactoring of the evas filters submodule. Use Ector.Buffer and the map/unmap methods instead of directly accessing image buffers with RGBA_Image. RGBA_Image is still used under the hood, for two reasons: - Required for the final output (blend onto Evas itself) - Required for the scaling routines FIXME: - Breaks proxy support (ie. all kind of texturing). - This breaks filters support for the GL engine.
2016-01-05ector: add engine-specific evas image buffer wrapperJean-Philippe Andre
Since Evas still relies entirely on Image_Entry and Evas_GL_Image, we will need an engine-specific wrapper object creating a Buffer around an existing cached image. Currently only SW support is implemented. GL will be more fun to do (with glReadPixels and whatnot).