This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
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
Give it sound files (ogg, wav, not mp3) as parameter or
"tone:freq=<f>,duration=<dur_in_s>" to play a lovely sine wave
* '<' and '>' seek forward and backward
* '+' and '-' change the volume
* Space toggles pause
* Shows information for the song (remaining, %)
* (Un)loop a song with 'l'
* 'n' - Next song
* 'm' - Next song simultaneous to current
* Volume can be set from 0 - 150%
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81001
Disabled by default, enable with --enable-audio
ALSA support is disabled as it is not there yet. Pulseaudio should work
though.
Support for .ogg and .wav is there as well (.mp3 is not)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 81000
By rudimentary I mean I barely got it to work. For my particular test
case. It will not work for you and needs lots of love until it can be
used.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80999
Very hackish implementation and probably not needed as libsndfile
virtual IO can be used instead, though it's a little more complicated
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80998
Allows reading from and writing to wav, ogg, etc. files. Support for
virtual IO as well to allow playing sounds from eet, which will be
needed in edje multisense.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80996
This is still very much a work in progress, so expect some issues. The
signalling is using ecore events for now - that will change to callbacks
you can register callbacks for events on specific Ecore_Audio_Objects.
EO wasn't there when Ecore_Audio started, but it will probably move to
that in the future.
Otherwise have fun, don't break it (too much) and please send bug
reports and feedback to me.
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80994
collateral damages that need further investigation. All programs running with
wayland engines are consuming 100% CPU.
ecore-wayland: Fix monitoring ECORE_FD_WRITE defaultly on
wayland display fd lead to 100% cpu usage
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Patch by: Alex Wu <zhiwen.wu@linux.intel.com>
SVN revision: 80981
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
Subject: [E-devel] [PATCH][Ecore] Fixes for invalid memory read issues
discovered by cppcheck
One more patch to fix issues discovered by cppcheck.
SVN revision: 80559
instead of -DHAVE_ECORE_X_XCB in the pc, which is a super-hack, add a
proper compile-time generated ecore_x_version.h that is included by
Ecore_X.h
This file contains HAVE_ECORE_X_XLIB or HAVE_ECORE_X_XCB defined and
will also define ECORE_X_VERSION_MAJOR and ECORE_X_VERSION_MINOR as
per other EFL (Ecore), also defining the runtime version in
Ecore_X_Version.
SVN revision: 80524
wayland display fd lead to 100% cpu usage
In ecore_wl_init(), adding wayland display fd with ECORE_FD_WRITE
flag make CPU usage 100%. The proper way to monitor the ECORE_FD_WRITE
is when the wl_display_flush() return value < 0 and errno == EAGAIN.
And if wl_display_flush() return, we remove ECORE_FD_WRITE flag from
the display fd.
Patch by: Alex Wu <zhiwen.wu@linux.intel.com>
SVN revision: 80476
still lots to do, but some improvements:
- ecore_evas does not inherit pkg-config from modules since modules are SO
- renamed internal ecore evas define from SOFTWARE_BUFFER to BUFFER,
to make consistent.
SVN revision: 80473
* a single option --with-evas-dither-mask=TYPE (big, small, line or none).
* make a wise decision to fallback to small dither mask for
conversions that do not support "no-dither" or "line". Before if
you did not specify it would fallback to big (128x128).
SVN revision: 80383
instead of the previous mess, just define the functions with common
names and call the backend that was compiled in, similar to what eio
does.
also do not be silent on errors, use eina_safety_checks to issue warnings.
SVN revision: 80360
Another try to make inotify checks more common.
This time uses AC_CHECK_HEADERS() as for others, that already define
HAVE_SYS_INOTIFY_H, then uses that.
I still kept AM_CONDITIONAL([HAVE_INOTIFY]) because I plan to convert
ecore_file to the same, smarter, method that is used in eio (compiling
the file depending on the backend.
SVN revision: 80358
* remove the option, as it shouldn't really exist.
* keep code, as requested by Cedric, someone may fix it someday. And
the default is the DISABLED, as the enable was broken.
* Add instructions on how to solve the problem, if a brave folk is up
to it.
SVN revision: 80352
* rename USE_GNUTLS and USE_OPENSSL to HAVE_GNUTLS and HAVE_OPENSSL
in ecore_con, to match other modules such as Eet.
* define requirements_pc_crypto, requirements_pc_deps_crypto and
requirements_libs_crypto so modules can use that.
* move to a common check section.
SVN revision: 80288
* remove EVAS_ prefix as it may be used by other libs some day.
* SSE3 is detected at runtime if x86.
* remove AC_SUBST([altivec_cflags]) as it was not being used anywhere.
* moved to top of file (maybe position is not optimal, let's wait
vtorri to review)
* simplified single-line summary that is as informative as before.
SVN revision: 80284
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280
Including ECORE_LIBS in LDADD is not enough, we have to include the
relevant libs from efl as well (eina, evas, ...)
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
SVN revision: 80260
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
Leandro Pereira
Cedric BAIL
Daniel Zaoui
Carsten Haitzler
ChunEon Park
Daniel Willmann
Leandro Dorileo
Alex Wu
Stefan Schmidt
Rui Seabra
Gustavo Sverzut Barbieri
Igor Murzov
Jihoon Kim
Sebastian Dransfeld
Sung Park
Flavio Vinicius Alvares Ceolin
Vincent Torri
Rafael Antognolli
Jiyoun Park
Sung-Jin Park
Gwanglim Lee