Thanks goes to Thiago Macieira for sharing the issue. This
is the result of the cross-desktop talk at fosdem. A lot more
comming in the futur !
SVN revision: 83578
Hi,
Can some one please verify and merge the attahed patch with open source svn Edje code.
[Issue details :]
NULL checking is not done before sending a string to strcmp().
In _edje_real_part_swallow() function of edje_util.c file, evas_object_type_get() API can return NULL and if
this NULL value is directly passed to strcmp(), it causes a crash.
[Issue fix :]
NULL check is added for obj_type before passing it to strcmp().
Thanks & Regards,
Sumanth
Signed-Off-By: Sumanth Krishna (sumanth.m@samsung.com)
SVN revision: 83393
This avoids blocking in eglSwapBuffers and has the side effect of
avoiding doing unnecessary work - painting where a frame won't be
presented.
We do this by using the event that the wayland compositor will send us
to tell us that the frame has been presented. Due to the fact that
evas_render_updates() could do no work and not cause a eglSwapBuffers we
must always have a frame callback listener setup.
Original patch by: Rob Bradford <rob@linux.intel.com>
(I just adjusted the patch to the single efl tree)
SVN revision: 83387
Always returning -1 for the frame duration does not have the desired
effect. Fix the logic checking whether eina_file_open has succeeded.
Animated GIFs play way too fast without this.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 83100
for direct rendering optimization. For direct rendering in EvasGL,
it falls back to FBO rendering if the conditions are not met. Before,
the fallback resources were created in the beginning but now they are
created and destroyed on need base.
SVN revision: 83057
This new engine function will only be used in software generic for
now - since it's the only engine used with the async render.
This function has been introduced in order to avoid growing thread
command queue too much to draw a text_props at a time on render calls
from textgrid objects.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82832
evas_gl_shader.c file and made an internal generic caching api in
evas_gl_common.h for use in other places ie. evas_gl.
Then implemented evas_gl surface cap. caching code in gl backend to
accelerate the engine creation.
SVN revision: 82321
Subject: [E-devel] 2 steps eina_share_common_del speed up
builtin node is never unlinked even if empty, always is the last of the queue,
so that it can be used to get a pointer to head.
cost: never unlink or promote builtin node.
benefit: no need to hash and search rbtree to unlink an empty node,
only to remove an empty head.
store full hash in Eina_Share_Common_Head, so we only hash once
use 8 lower bits as node hash, use next 8 bits as bucket index.
cost: have to apply 0xFF mask on hash in rbtree callbacks.
benefit: no need to hash when removing an empty head.
SVN revision: 82161
Changes also in this commit:
* fix missing EAPI in symbols used by modules
* removed old libudev and libmount support as agreed by discomfitor/zmike
* replaced __UNUSED__ with EINA_UNUSED
* fixed docs hierarchy
SVN revision: 82100
it's useful to copy file from one place to another and this will be
used in eio' s implementation.
NOTE: did not use mmap here as mmap faults may be cumbersome to handle
(Eina_File itself does that, but in a nasty way) and the
implementation would be severely different as there is no Eina_File
from FD, and there is no way to inject custom memory/fd into the
Eina_File's fault handling. The performance would not be that
different anyways and the splice() is already in there for systems
with good performance (read: Linux).
SVN revision: 81942
This function was basically never working correctly. Everything was
fixed by simulating the evas_object_image_render() workflow, but
instead of actually draw we just check the pixel transparency.
Bugs fixed:
* fails when image is scaled up (could segv) or down (incorrect values);
* fails when image is moved to negative x,y;
* fails when border was being used.
Now everything is fixed and seems to work properly, except I'm not
handling the map and get_pixels() cases, these are marked with ERR()
so we can fix them if someone needs.
SVN revision: 81410
Whenever we copy an image, making it write-able
(evas_object_image_data_get(o, 1)) or just start painting a pristine
buffer (evas_object_image_size_set(o, w, h)), we must mark the image
as loaded to avoid trying to load it (and failing, marking the whole
thing as EVAS_LOAD_ERROR_GENERIC).
SVN revision: 81409
line position is slightly different between gl drivers.
I have no idea why it is. So added to work differently based on the manufacturers.
This work may be based on the renderer. If you can test it with much drivers then please test and fix.
Also changed the ENV name from EVAS_GL_LINE_NO_OFFSET_HACK to EVAS_GL_LINE_OFFSET_HACK_DISABLE.
SVN revision: 81016
Report from Klocwork. I checked that the actual max size of the name is
13 bytes. Now we allocate one more to hold the terminating NULL byte and
not write into unallocated memory.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80773
I tested gl line drawing on a few devices and found the x line start position was 1.
On the other hand, our evas draws the line on start position 0.
So it needs to shift by 1 pixel if evas is working on gl backcned.
SVN revision: 80734
Thanks to PrinceAMD (Deon Thomas) for bugging me to implement this,
then test and add a fix, now we can implement something similar to
"xterm -e" in terminology.
ECORE_GETOPT_ACTION_BREAK will allow generic options to behave the
same as GNU's --, breaking out of argument parsing logic.
SVN revision: 80619
After agreement in the mail list, core developers agree to remove this
engine that was not being supported for a long time.
Given that most operations Evas uses are not accelerated in DirectFB,
or at least hardware that exclusively supports DirectFB, it's better
for those people to just use Evas/Ecore software (buffer) rendering
and expose DirectFB's framebuffer as destination surface.
SVN revision: 80232
Subject: Re: Re: Re: [E-devel] [RFC] Virtual desktop window profile
I've attached 4th patch. May the 4th be with you.
ecore patch has been merged with efl and all files are based on r80123.
Thanks & Regards,
Gwanglim
------- Original Message -------
Sender : Daniel Juyung Seo<seojuyung2@gmail.com>
Date : 2012-12-04 01:55 (GMT+09:00)
Title : Re: Re: [E-devel] [RFC] Virtual desktop window profile
It looks ok to me.
Sorry but can you re-generate the patch according to the recent ecore
merge to efl single tree?
Daniel Juyung Seo (SeoZ)
On Thu, Nov 29, 2012 at 12:29 AM, Gwanglim Lee <gl77.lee@samsung.com>
wrote:
Dear Raster and Daniel Juyung Seo,
I've attached 3rd patches and test_config according to your reviews.
These are based on r79782.
[elementary & ecore]
1. "profile,set" -> "profile,changed" - done
2. spaces after EINA_LIST_FOREACH - done
3. variable type - keep
4. author - done
5. removing deprecated marking in patch - done
6. add elm_win_available_profiles_get to test_config for the debugging
purpose - done
7. check whether a given profile is present in an available profiles.
otherwise window profile will be one of the item
in available profiles. - newly added thing to the elm_win
8. merge with EO - done. :(
Any comments would be appreciated.
SVN revision: 80214
there are some early-return code that were leaving the size_hint as it
was before, then if you removed every child it should go to 0x0 but
couldn't.
PLEASE BACKPORT THIS TO 1.7 BRANCH FOR ME :-(
SVN revision: 79948
direct rendering and then another image object using Native
Surface rendering, there was a potential for it to fall into
the same direct rendering path.
Also, fixed some minor Evas GL extension bugs that came from refactoring.
SVN revision: 79532