When compiling src/bin/edje, we end up with compiler warnings about
'pc' variable being set but not used. This patch just comments out
(for now) those variables (as I am unsure if they are going to be used
later or not).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This is a follow up on the previous commits.
The original patch on Phab was split in 3 parts (factorization,
fix & this one).
Adds support to both SHM and EGL.
See D3501.
Summary:
Add TBM surface in wayland and clean up Native struct on Evas Engine.
Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend.
This patch has the code for wayland backend.
In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common.
And, Native in Evas_Engine is clean-up.
@feature
Test Plan:
TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device.
Pixmap surface is tested in ubuntu with same test app.
EvasGL is tested with elementary_test.
Reviewers: jpeg, spacegrapher, raster, cedric
Subscribers: dkdk, scholb.kim, JoogabYun
Differential Revision: https://phab.enlightenment.org/D3501
This implements a generic way of scaling buffers, using fake
RGBA_Image wrapping ector buffer maps. The underlying algo is
still the good old linear sw scaler.
Now the filters *should* be back to their previous level of
usability. Performance will probably be even worse than it was
before, for GL, as more glReadPixels may be involved. Optimization
now consists in actually implementing the filters with GL shaders.
Now the filters should work with the GL engine, again, but with
a potentially crazy performance. Indeed, the input buffer is now
backed by an FBO, that needs to be glReadPixel'ed everytime it is
accessed by the filters (mapped).
Evas filters is now more and more unaware of evas images (RGBA_Image)
and the engine + ector take care of everything.
Still left to do:
- map / unmap an FBO buffer into RO or RW memory
Dumb implementation of a "smart" buffer capable of wrapping an
RGBA_Image but that can still be rendered on screen (ie, an
Evas_GL_Image is attached to it).
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
Since Ector Buffer implicitly converts colorspaces, we
can allow more commands to work even if they are suboptimal.
Now all filters should support any combinaison of input, map/mask
and output colorspaces.
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.
This indicates that a buffer can be used as a source to draw pixels.
Can't they all do that? Well, not exactly. A CPU buffer can't be drawn
by the GPU... not directly at least. That's what this flag is for.
In case you map a buffer once for read-only and once for write,
we can generate a temporary copy and return that instead. This
buffer will be copied back to the original surface once the COW
surface is unmapped.
Also use map to generate spans.
This should simplify some filters code, making things work,
albeit inefficiently. At least they should work.
Fix doc too.
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).
It just makes things a bit more complicated and doesn't correspond
to a classic "map" operation anyways.
Also return void* instead of uint8_t*. This is more correct and
avoid extra casts.
Summary:
edje_cc does not check whether insert_before/after part exists.
edje_cc will notify a compilation error to developer when insert_before
or insert_after part does not exist.
T2513
Reviewers: Hermet, NikaWhite
Subscribers: cedric, jpeg
Maniphest Tasks: T2513
Differential Revision: https://phab.enlightenment.org/D3517
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
There were some problems with second and third vertices in the first triangle of convex hull. It is very hard to see this errors because it could cause
an excess of triangles inside of convex hull, I have used blender to find them.
Reviewers: raster, Hermet, cedric
Reviewed By: cedric
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D3491
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
I have a strange feeling that I always commit the same code to edje-3d, I hope it will finish very soon.
However here are some important new keywords, descriptors for them, methods for models,
structure for providing animation in edje programs and some more changes.
Reviewers: raster, Hermet, cedric
Reviewed By: cedric
Subscribers: jpeg, artem.popov
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3437
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Changed ecore_con_connector.eo to efl_network_connector.eo as part of
migrating to efl_network.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3427
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
The example is to demonstrate the use of
eina_strbuf_manage_read_only_new_length API.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D3421
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Before adding of new saver and loader for ply format we had a chance to set EVAS_CANVAS3D_SHADE_MODE_VERTEX_COLOR
for every mesh, now we save only existing atributes and there are a lot of meshes we have to set EVAS_CANVAS3D_SHADE_MODE_VERTEX_COLOR.
[FIX]
Reviewers: cedric, raster, Hermet
Subscribers: jpeg, artem.popov
Differential Revision: https://phab.enlightenment.org/D3412
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Chris Michael
Stefan Schmidt
Jean-Philippe Andre
Wonsik Jung
Cedric BAIL
Amitesh Singh
Srivardhan Hebbar
Jee-Yong Um
se.osadchy
perepelits.m