| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The memory usage graph was going up and to the right!
I was told this is always a good thing!
... maybe not this time :)
Hopefully I didn't forget a case. An intense session of
genlist scrolling with masks all over the place and masks
of masks didn't show any glitch, crash or memory leak.
|
|
Move some mask object pointers around to spare a few
bytes of memory.
Fixes T2025.
|
|
The main difference between 1.12 and 1.13 memory foot print is actually
related to this two pointer to mask. I am wondering if there is not an
issue here also has we do have a duplicated pointer. We have prev_mask
and mask in both cur and prev state of an Evas_Object, but only mask
and prev_mask from the cur state seems to be accessed.
If we can remove two pointers from those state, we should have a decent
win in expedite benchmark. Hopefully 300KB to win there (Close to half
the additional cost in memory).
|
|
|
|
The flag should be set on the mask itself.
Checking for (x,y) being inside the mask can be an expensive operation,
so further optimization will be required.
|
|
Summary: This fixes CID1261436: unintentional integer overflow
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
|
|
Summary:
There was no conversion to the double quotation mark in the evas_textblock_text_utf8_to_markup function.
The price of the text coming out to API and text coming out to Textblock was different as a result.
As a result, Two text lengths came out differently.
So, I added the exceptional treatment part in the evas_textblock_text_utf8_to_markup function.
@fix
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1853
|
|
Summary:
There will be several methods to set orientation in edc, so we have decided to make one big vector,
the main reason is that we use quaternion by default, but look_at, for example, is given as 6 coordinates.
Reviewers: Hermet, cedric, raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1693
|
|
this fixes artifacts if you have cells with 0 codepoints and also have
underlines or strikethroughs in them.
@fix
|
|
this matches 83eb1aa3c2e15568c89546048d72d7cae071ee42 fix in the other
map render func
|
|
Well... actually this is not exactly a fix.
It just restores the previous behaviour, and allows AA to
work. As in, it won't draw ugly black lines but properly
blend to transparent.
But there is still a problem:
The image map render function changes the alpha flag on the source
image if AA is enabled or if the map has an alpha color. This is
actually wrong as images forcefully set to not have any alpha
(with evas_object_image_alpha_set(0)) will then not be opaque
anymore.
Right now I can't think of a solution (also I don't quite follow
the entire pipeline in evas map...). Changing the flag will
make some opaque areas transparent. Not changing the flag will
produce ugly artifacts where AA blending should happen. Fix one
bug and the other appears, and vice versa.
This can be tested with the example evas-map-aa and adding an
alpha channel to cube1.png (with gimp for instance) but manually
setting alpha to 0 in the code. Weird stuff will happen (try
playing with the map and pressing I to switch to/from image mode).
|
|
Don't change a source image alpha flag at render time.
It doesn't make sense at this point.
Also remove unused int pa.
|
|
this fixes a feature added in this version of efl. as above.
|
|
Untested. Just skip pixman path when there's a mask.
|
|
The proper geometry should be set when rendering the mask,
otherwise we can't create a new surface if it changed dimensions.
|
|
|
|
The selected op func was not performing the correct operation,
thus producing rendering artifacts. These functions should not
be used anywhere except in case of masking... which was not an
available option earlier.
It was doing (wrong):
dst = interp(mask, src, dst)
Instead of (correct):
dst = dst + (1 - mask) * src
NOTE:
This commit also disables MMX, SSE3 & NEON implementations of
pixel_mask blend operations, since they are also broken.
|
|
|
|
|
|
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
|
|
In case the clipper is a mask object, we should use precise
event masking. By default precise_is_inside is not enabled
because it is expensive, but it should probably be set by
the application when they use masks as clippers.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
|
|
This implements supports for masking inside evas_render, which
means:
- Render the mask itself into a surface (ALPHA if possible)
- Pass this mask surface to the draw context
- Apply mask recursively in case a masked object is contained
by another masked object.
@feature
|
|
The render function is not yet implemented, but this
prepares the infra used to set an object other than
Rectangle as a clipper.
@feature
|
|
This allows passing a mask image to the render functions.
@feature
|
|
Work done by Jaeun Choi, rebased & squashed by jpeg.
This commit introduces changes to the low-level draw functions
of the SW engine considering the existence of an alpha mask image.
Features:
- Font masking (TEXT, TEXTBLOCK),
- Rectangle masking,
- Image masking (all image scaling functions should be handled).
The mask image itself is not yet set in the draw context (see
following commits).
@feature
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
|
|
Reviewers: cedric, Hermet
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1851
|
|
So I've discovered some weird output values after drawing
some text. The destination alpha would become 0xFE even
when the back buffer had a background with 0xFF alpha.
Example:
Dest is 0xff00ff00 (green).
Color is 0xffffffff (white).
Current font alpha is 170 (0xaa).
--> Output was 0xFEaaFEaa instead of 0xFFaaFFaa.
This is because of some slightly invalid calculation
when doing the font masking (mtab[v] = 0x55 above).
Indeed, MUL_256 takes alpha values in the range [1-256]
and not [0-256] as was assumed.
|
|
Even so return a more meaningful value - 0 is not a member of the Enum it returns.
|
|
Summary:
Calling eina_inarray_free to fix the memory leak issue in the error condition.
@fix
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1809
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
|
|
|
|
|
|
|
|
|
|
*file.
|
|
model_save_load. Changing API in examples.
|
|
similar to functions in image_save_load process.
|
|
|
|
image_saver_loader.
|
|
this fixes T1946
|
|
|
|
|
|
|
|
|
|
Summary: Rewrite linline assembly in mapping func using NEON intrinsics.
Reviewers: raster
Differential Revision: https://phab.enlightenment.org/D1740
|
|
We don't use magic since moving to Eo.
|
|
There was a problem when checking whether the current surface
is compatible with direct rendering. In case of client-side
rotation (it's a flag set on the surface by the app), a surface
can be directly rendered even if the rotation is not 0.
But, before this patch, it was assumed that the surface was
current. Which doesn't make sense because make_current is
called by the pixel callback, from the application, and this
happens *after* we check for direct rendering.
As a consequence, it was not possible to mix directly rendered
surfaces with FBO-based ones, and use client-side rotation.
This patch should solve that issue.
|
|
This should ensure that the difference between the original
pixel value and the rle4 encoded one is <= 8.
The previous fix was a bit stupid as it was not taking into
account the conversion a4 to a8 (which is a8 = (a4 << 4) | a4).
|
|
This is an attempt at having higher quality font rendering
while still using RLE-based font compression.
|
|
Reviewers: zmike, devilhorns, cedric, gwanglim
Reviewed By: cedric, gwanglim
Subscribers: jpeg, torori, cedric
Differential Revision: https://phab.enlightenment.org/D1507
|
