This is what the old shm code has been doing, and it's probably better
than what the dmabuf code was doing.
We currently allocate 3 buffers. The usual case has us swapping between
two of those buffers and saving that third buffer for emergencies - if
we ever need that third buffer it'll require a full redraw.
If we return the oldest available buffer the usual case requires a little
more damage but we should never hit the full redraw case, which can cause
a frame drop on slow hardware.
Now that we're dependent on create_immed there's no possibility of falling
back to non dmabuf allocation.
The only failing case we really need to handle is failing the first
allocation, which is currently broken and I'll be adding an advance test
for it shortly.
wl_shm and dmabuf only really need to differ in how they allocate a buffer,
but right now we've got them in separate files. This dramatically
reduces the complexity of the wl_shm code and shares much more
implementation with the dmabuf code.
This throws away at least one "optimization" wl_shm used - over-allocating
buffers so that window resizing doesn't always require a new buffer
allocation. If people feel that window resizing has become too slow now
this can be added to the dmabuf code to the benefit of both allocators.
Disabling dmabuf by env var still uses the old wl_shm implementation for
now, but soon that code will be removed entirely and the env var disable
will use this path.
Summary:
Refactoring.
It is good to store values from that struct in a parsing/loading context
static variable is a big NO NO:
1. Ugly code design,
2. Might not work when trying to load more than one SVG file.
@fix
Reviewers: jpeg, smohanty
Subscribers: jenkins, cedric
Differential Revision: https://phab.enlightenment.org/D5399
Accodring to https://www.w3.org/TR/SVG/types.html#Length
length ::= number ("em" | "ex" | "px" | "in" | "cm" | "mm" | "pt" | "pc" | "%")
This is still work in progress since some of lengths should be treated
differently, for example gradient lengths
Just as a starter to make a working background that, later on, will go
through Svg_Node's and build a certain source code to be saved in SVG
picture as a file
Coverity reports that we access vfmapped here without holding a lock.
This patch implements eina_lock_take/release while accessing
priv->vfmapped.
Fixes Coverity CID1381624
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports that _evas_dmabuf_buffer_init function here can
potentially free the surface that was passed into it. If that happens,
we should not be calling the _fallback function with surface as the
parameter as that will directly dereference the freed pointer.
Fixes Coverity CID1381707
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In most engines which inherit from software_generic, they do not
implement the outbuf_free_region_for_update function. Most engines
have it as an unused function. If we simply add a check here, then we
can reduce the need for having useless function in multiple engines.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This prevents legacy EO classes from being exposed through .eo.h headers
or .eo in share/eolian/includes. Also removes a slew of useless xxx_eo.h
intermediate headers.
Notes:
- elm_systray has no proper API: it's not clear if the EO API should be
released (in which case it needs to be renamed to efl_something) and
there is no legacy API to create a systray object.
- Some files have been placed in a "FIXME" section, as I believe they
are necessary within EO land, but at the same time still don't
conform to the interfaces (eg. name starts with elm_).
- elm_interface_scrollable is required by photocam. This means photocam
needs to be adapted to fit the EO scroller API (still to be
completed, I believe).
Bugs:
- This breaks most C++ examples. I KNOW. And I'm working on it.
Ref T5301
This isn't meant to be installed. The canvas API in EO is based around
the interfaces Efl.Canvas and the widget Efl.Ui.Win. Anything else is
not EO (eg: ecore_evas, evas, ...)
Note: evas_canvas3d is the last remaining thing that is installed along
EO files, but those are all beta APIs.
Turns out when apps reconnect to the compositor they don't always
realize they need to redraw themselves. Force a manual render
at startup if we end up in a state where an update is needed but
has probably been dropped on the floor.
If the image has no data, it may get an allocated surface of 1x1 but it
is not sane to return the pointer to that data, as the user would expect
a normally sized image (in my case, 1920x1080).
I do not fully understand what is going on with this image. But at least
this transforms a crash into a simple ERR in ~/.xessions-errors
Two similar crashes happened:
- SIGSEGV by writing data outside of the image data
- abort() in free() because the malloc metadata has been overridden
when writing outside of the image data (newly allocated 1x1).
Fixes T5957
@fix
this is normal - brute force trying loaders until one succeeds is
normal is etn doesnt help identify it or it fails the first
guess-by-extension. printing errors is not good as this is an ok and
EXPECTED error. slience!
@fix
This is really several inseparable commits mashed together, as doing this
a piece at a time would introduce broken intermediate revisions.
Double buffer incoming "configure" state from the compositor so it's held
back during asynchronous render and processed at frame completion.
Hold off on certain requests if their API has been invoked during async
render.
This should fix a lot of races, cosmetic issues, issues where weston can
kill our clients for acking configure (or not) at bad times, etc.
We've really always needed to do immediate creates. On a surface resize
there's no place to wait for the round trip for the new buffers to exist.
We've gotten away with this until now by good luck because we dispatch
wayland events during asynchronous render. However, with async render off
or if schedule happens in an unfortunate order, we can end up with
tearing.
Outbuf shouldn't have to track its hidden status, that should be ecore_evas
problem. Until now we were doing this because our kludgey wayland
ticking made things difficult, but I think it's safe to remove now.
Calls to gst_video_frame_unmap should take a GstVideoFrame as a
parameter (not a buffer). I believe this was the intended function
here (to unmap the video frame), so fix the call to not pass a
GstBuffer.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports passing a null pointer 'im->gc' to
evas_gl_common_context_flush which directly dereferences it, so lets
be sure that 'im->gc' is valid before passing it to context_flush
Fixes CID1374273
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports that there may be a null pointer dereference here so
check that 'error' exists before trying to set it.
Fixes CID1374272
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds support for doing output rotations via hardware. This
is implemented inside the Ecore_Evas engine so that it is transparent
to the caller of ecore_evas_rotation_set.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
Small patch to fix Coverity reported issues of uninitialized variables
Fixes CID1381306, CID1381305, CID1381304, CID1381303
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds support for software rotation in the evas drm engine.
This is a fallback codepath in case hardware rotation is not supported
for a given rotation amount. This patch also fixes a leak of and
pending updates during output buffer free.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch provides an override in the evas drm engine for the output
resize function. We override this function so that we can reconfigure
the output buffer.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The chained mempool uses eina trash to dispose and retrieve memory
blobs. Problem is that eina trash requires the memory blobs to be at
least of the size of a pointer. If the size of an element in the mempool
is less than the size of a pointer, which _is_ possible as no minimal
size is enforced, eina_trash will silently corrupt the memory pool.
To prevent memory corruption while still allowing small elements, the
size of an element defaults to the size of a pointer if it was smaller.
This comes at the cost of consuming slightly more memory in these cases,
but at least the memory pool can be safely be used.
@fix
Derek Foreman
Carsten Haitzler
Vitalii Vorobiov
Jean-Philippe Andre
Chris Michael
Subhransu Mohanty
Cedric BAIL
Mike Blumenkrantz
WooHyun Jung
Prince Kumar Dubey
Youngbok Shin
Vincent Torri
Jean Guyomarc'h