There is no meaning in negative values for image loading, marking as
dirty or size, so image internals (cache, entry) were changed to
unsigned, reducing possible errors, particularly with overflow.
engines were converted to the new way, but any 3rd party modules will
still work as they should be using values >= 0 only anyway.
please review.
new cases introduced by "comparison between signed and unsigned" were
fixed in the modules that used cache_entry or Image_Entry dimensions.
SVN revision: 52428
*client->server renamed client->host_server to clarify ambiguity
*ecore_con_ssl_client_prepare.* killed off because it was useless and wrong
*openssl generates only one SSL_CTX per server now instead of a new one for each client, which is broken/unnecessary/wasteful
**as a result, certificate loading is now only done once
**additionally this will save a very large amount of memory and avoid unnecessary/broken refcounting
*ecore_con_ssl_server_prepare.* rewritten to actually be useful instead of just a lazy way to null pointers
**all SSL_CTX code now goes here^
*some formatting fixes
*internal function renames
SVN revision: 52422
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
soft16 was written as a single engine, thus it was all static/global
and had no EAPI in its functions, but then it was moved into
"src/lib/common_16" and got that, but got no prefix! That could cause
clash with other libraries, so adding such prefix.
soft8 was a copy of 16, thus had the same problems.
the engines were all based on software_x11, thus they defined the same
methods to deal with Xlib, however if you link them all in the same
binary (--enable-MODULE=static), the symbol would be redefined. Rename
symbols according to their module.
SVN revision: 52420
Advantages:
* it is the simplest method to implement
Disadvantages:
* it's slow
* it does not take into account transparency
* it does not work with the composite manager (Windows >= Vista)
Layered windows should be used (all the disadvantaged above are
fixed), but i've never succeeded in making them work.
SVN revision: 52416
Make this function recursive, so it can adjust the coords for all
parent objects. It starts with the grand-grand-grand-...-parent and goes
down until the same object.
SVN revision: 52407
We are iterating EINA_INLIST_REVERSE_FOREACH(list, obj) in a recursive
function. Don't mark the other objects as havemap_parent if the first
in the list has it.
SVN revision: 52403
The solution is that we only delete invisible standalones now, not visible ones, this is correct intuitively and of course fixes the bug.
SVN revision: 52302
Some inputs in which tmp - cur is greater than the number of previous nodes
in list, were causing ct to be null at end of loop.
Patch by Jonas M. Gastal <jgastal@profusion.mobi>
SVN revision: 52253
NOTE: If you have swallow or parts that where constrained by min and
max, and you used aspect on them, expect change on your layout.
SVN revision: 52244
I removed a function that caused the issue and made no sense at all, honestly, it didn't make any sense.
I did a lot of testing trying to see if there are any new bugs after the fix, and nothing, so I guess my instincts were correct.
Please if you can, check out the removed function (_layout_walk_back_to_item_word_redo) and see if it makes any sense to you, if it does, please let me know.
SVN revision: 52243
Add two new canvas level callbacks: OBJECT_FOCUS_IN/OUT
As we already had callbacks for objects gaining or losing focus, then
two more for the Canvas, now we can have the entire Evas be notified when
any object changes its focused status. The object in question is passed
as the event_info for the callback.
SVN revision: 52196
Assert cache->usage never becomes negative as was occurring before the
fix in r52149.
Just in time, the fix in r52149 was made by Ulisses, not me.
SVN revision: 52190
Essentially the problem is this: For drag and drop Ecore currently handles the
position update calls. But usually the application wants to display some user
feedback - a window to display the drag selection for instance.
Now the way e17 does it is grab the mouse cursor movements and track them
itself. However ecore is already doing this, it's already walking window
trees, calculating real positions, _and_ sending them in an X client message.
So it seems rather silly to duplicate the code in the user app to get the same
info.
We could possibly have added a new event, but then we need to deal the fact
the position update may arrive _After_ the item has been dropped. Hilarity
ensures[1].
This callback is meant for purely the selection owner of the drag to use, so
it is a callback set, not an add.
[1] Segfaults probably. Nothing funnier.
SVN revision: 52181
Memory usage was not accounted right because
cache->func.mem_size_get(ie) returns 0 when called after
cache->func.destructor(ie). Thus the total memory used, kept on
cache->usage, is never decremented in _evas_cache_image_remove_activ()
This implies that cache->usage will keep growing and eventually it will
overflow, becoming negative. So evas_cache_image_flush() will not do its
job because cache->limit (assumed to be positive) will not be less than
cache->usage anymore. So the total memory allocated will start to grow
and the limit won't be respected.
Strictly speaking, it's not a leak, since all the memory will be
eventually freed when evas shutdown is called, but the program might be
killed by over allocating memory. This is caught by valgrind with the
massif tool. The graphic below shows that in the end a huge memory amount
is allocated. This is the moment when cache->usage became negative.
MB
26.04^ #
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| :::::::::::::::::@@:::::::::@:::@::::::@::::::::::::::::::::::::::#::::
| : ::: ::: ::: :::@ :: ::: : @:: @:: :::@: :: ::: : : :: :: : ::: :#::::
0 +----------------------------------------------------------------------->Gi
0 54.83
This patch is a one line fix, which swaps the calls to
_evas_cache_image_remove_activ() and cache->func.destructor() making
cache->limit to be respected.
SVN revision: 52149
Instead of relying on the value of edf (and having to set it on all
places to NULL) jump to 'open' label on the only possible case of the
control flow.
SVN revision: 52132
Calling help in edje_player was showing the wrong order for sending a signal.
The right order is the same of the function edje_object_signal_emit()
SVN revision: 52105
Lowering priority was wrong. Some bugs:
1) You don't lower the priority by setting the scheduler policy to some
of the real-time ones (SCHED_RR or SCHER_FIFO). If you do so, you are
actually increasing the priority of the workers and your main thread
you be preempted and stalled until the workers complete their job.
Fortunately this will only happen if your programming is running as
root, as normal users (without CAP_SYS_NICE) are unable to set
priority to real-time values.
2) setpriority() and getpriority() are not part of pthread and you can't
use the id returned by pthread. Manpage explicitly says so on
pthread_self(3):
"The thread ID returned by pthread_self() is not the same thing as the
kernel thread ID returned by a call to gettid(2)."
Since glibc does not have a gettid, here we are using
syscall(SYS_gettid)
This patch was tested with the program below. Compile and run:
$ gcc p_hello2.c -o p_hello2 -lpthread
$ ./p_hello2 10
You'll see that the main thread remains with its priority and threads
created by the main thread change their own niceness.
#include <errno.h>
#include <pthread.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/types.h>
/* Lower priority of current thread.
*
* It's used by worker threads so they use up "bg cpu" as it was really intended
* to work. If current thread is running with real-time priority, we decrease
* our priority by 5. This is done in a portable way. Otherwise we are
* running with SCHED_OTHER policy and there's no portable way to set the nice
* level on current thread. In Linux, it does work and it's the only one that is
* implemented.
*/
static void
_ecore_thread_pri_drop(void)
{
struct sched_param param;
int pol, prio, ret;
pid_t tid;
pthread_t pthread_id;
pthread_id = pthread_self();
ret = pthread_getschedparam(pthread_id, &pol, ¶m);
if (ret)
{
fprintf(stderr, "Unable to query sched parameters\n");
return;
}
if (pol == SCHED_RR || pol == SCHED_FIFO)
{
prio = sched_get_priority_max(pol);
param.sched_priority += 5;
if (prio > 0 && param.sched_priority > prio)
param.sched_priority = prio;
pthread_setschedparam(pthread_id, pol, ¶m);
}
#ifdef __linux__
else
{
tid = syscall(SYS_gettid);
errno = 0;
prio = getpriority(PRIO_PROCESS, tid);
if (errno == 0)
{
prio += 5;
if (prio > 19)
prio = 19;
setpriority(PRIO_PROCESS, tid, prio);
}
}
#endif
}
/*
* p_hello.c -- a hello program (in pthread)
*/
#define MAX_THREAD 1000
typedef struct {
int id;
} parm;
void *hello(void *arg)
{
parm *p=(parm *)arg;
pid_t tid;
int prio;
tid = syscall(SYS_gettid);
printf("[%d] Hello from node %d\n", tid, p->id);
pthread_yield();
printf("[%d] HELLO!\n", tid);
_ecore_thread_pri_drop();
prio = getpriority(PRIO_PROCESS, tid);
printf("[%d] New nice value: %d\n", tid, prio);
return (NULL);
}
int main(int argc, char* argv[]) {
int n,i;
pthread_t *threads;
pthread_attr_t pthread_custom_attr;
parm *p;
pid_t tid;
int prio;
if (argc != 2)
{
printf ("Usage: %s n\n where n is no. of threads\n",argv[0]);
exit(1);
}
n=atoi(argv[1]);
if ((n < 1) || (n > MAX_THREAD)) {
printf ("The no of thread should between 1 and %d.\n",MAX_THREAD);
exit(1);
}
threads = (pthread_t *)malloc(n * sizeof(*threads));
pthread_attr_init(&pthread_custom_attr);
p = (parm *)malloc(n * sizeof(parm));
/* Start up thread */
tid = syscall(SYS_gettid);
for (i=0; i<n; i++) {
prio = getpriority(PRIO_PROCESS, tid);
printf("[%d] root thread nice value: %d\n", tid, prio);
p[i].id=i;
pthread_create(&threads[i], &pthread_custom_attr, hello, (void *)(p+i));
}
/* Synchronize the completion of each thread. */
for (i=0; i<n; i++) {
pthread_join(threads[i],NULL);
}
free(p);
return 0;
}
SVN revision: 52040
Lowering priority was wrong. Some bugs:
1) You don't lower the priority by setting the scheduler policy to some
of the real-time ones (SCHED_RR or SCHER_FIFO). If you do so, you are
actually increasing the priority of the workers and your main thread
you be preempted and stalled until the workers complete their job.
Fortunately this will only happen if your programming is running as
root, as normal users (without CAP_SYS_NICE) are unable to set
priority to real-time values.
2) setpriority() and getpriority() are not part of pthread and you can't
use the id returned by pthread. Manpage explicitly says so on
pthread_self(3):
"The thread ID returned by pthread_self() is not the same thing as the
kernel thread ID returned by a call to gettid(2)."
Since glibc does not have a gettid, here we are using
syscall(SYS_gettid)
This patch was tested with the program below. Compile and run:
$ gcc p_hello2.c -o p_hello2 -lpthread
$ ./p_hello2 10
You'll see that the main thread remains with its priority and threads
created by the main thread change their own niceness.
#include <errno.h>
#include <pthread.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/types.h>
/* Lower priority of current thread.
*
* It's used by worker threads so they use up "bg cpu" as it was really intended
* to work. If current thread is running with real-time priority, we decrease
* our priority by 5. This is done in a portable way. Otherwise we are
* running with SCHED_OTHER policy and there's no portable way to set the nice
* level on current thread. In Linux, it does work and it's the only one that is
* implemented.
*/
static void
_ecore_thread_pri_drop(void)
{
struct sched_param param;
int pol, prio, ret;
pid_t tid;
pthread_t pthread_id;
pthread_id = pthread_self();
ret = pthread_getschedparam(pthread_id, &pol, ¶m);
if (ret)
{
fprintf(stderr, "Unable to query sched parameters\n");
return;
}
if (pol == SCHED_RR || pol == SCHED_FIFO)
{
prio = sched_get_priority_max(pol);
param.sched_priority += 5;
if (prio > 0 && param.sched_priority > prio)
param.sched_priority = prio;
pthread_setschedparam(pthread_id, pol, ¶m);
}
#ifdef __linux__
else
{
tid = syscall(SYS_gettid);
errno = 0;
prio = getpriority(PRIO_PROCESS, tid);
if (errno == 0)
{
prio += 5;
if (prio > 19)
prio = 19;
setpriority(PRIO_PROCESS, tid, prio);
}
}
#endif
}
/*
* p_hello.c -- a hello program (in pthread)
*/
#define MAX_THREAD 1000
typedef struct {
int id;
} parm;
void *hello(void *arg)
{
parm *p=(parm *)arg;
pid_t tid;
int prio;
tid = syscall(SYS_gettid);
printf("[%d] Hello from node %d\n", tid, p->id);
pthread_yield();
printf("[%d] tid=%lu\n", tid);
_ecore_thread_pri_drop();
prio = getpriority(PRIO_PROCESS, tid);
printf("[%d] New nice value: %d\n", tid, prio);
return (NULL);
}
void main(int argc, char* argv[]) {
int n,i;
pthread_t *threads;
pthread_attr_t pthread_custom_attr;
parm *p;
pid_t tid;
int prio;
if (argc != 2)
{
printf ("Usage: %s n\n where n is no. of threads\n",argv[0]);
exit(1);
}
n=atoi(argv[1]);
if ((n < 1) || (n > MAX_THREAD)) {
printf ("The no of thread should between 1 and %d.\n",MAX_THREAD);
exit(1);
}
threads = (pthread_t *)malloc(n * sizeof(*threads));
pthread_attr_init(&pthread_custom_attr);
p = (parm *)malloc(n * sizeof(parm));
/* Start up thread */
tid = syscall(SYS_gettid);
for (i=0; i<n; i++) {
prio = getpriority(PRIO_PROCESS, tid);
printf("[%d] root thread nice value: %d\n", tid, prio);
p[i].id=i;
pthread_create(&threads[i], &pthread_custom_attr, hello, (void *)(p+i));
}
/* Synchronize the completion of each thread. */
for (i=0; i<n; i++) {
pthread_join(threads[i],NULL);
}
free(p);
}
SVN revision: 52039
Fixed formatting issues.
Fixed typos.
Fixed clearing of selection when pressing a key in a software keyboard.
Patch by Jihoon Kim and small adjustments by myself. Thanks a lot.
SVN revision: 51897
from our debian/ dir? i dont know what debian and ubuntu will one day
use for their pkging info.. but at least have the stuff we have in svn
work eh? :)
SVN revision: 51858
done. working. now... still 1 more bug. seems to be a changed flag bug
too in dlip 2 test in scrolling list after map anim finished. smaller
bug to deal with now. ugh. bug one bug to the other
SVN revision: 51849
If there isn't a font, the hash is NULL.
So, just check before to avoid problems.
Moreover, removing one line that had been lost in code generate of
fonts parts and moving it declaration for the right context
By: Fabiano Fidencio <fidencio@profusion.mobi>
SVN revision: 51786
it? and... lets not just throw pointer onto pipelines just for the
hell of it.. as like.. hmm the object owning the pointer might be
freed before pipelien finishes.. or hell. it might change pointer
contents? :) need to nwo dup bidi intl_props. probably a better plan..
tasn looking at you... is to fix up evas bidi utils and make the intl
props a new/free thing (and sharable eh?) with reference counts to
avoid dups (just ref up most of the time - and if u change, make a new
intl prop - dont change current one) etc. etc. for now dup - this
gives a perf hit tho. at least async rendering works now.
SVN revision: 51736
The offending projects were:
E16/e/src/backgrounds.c | 10 ++++------
PROTO/eon/src/lib/layout/eon_stack.c | 4 +---
ecore/src/lib/ecore_win32/ecore_win32.c | 3 +--
ecore/src/lib/ecore_wince/ecore_wince.c | 3 +--
edje/src/lib/edje_edit.c | 3 +--
evas/src/lib/cache/evas_cache_image.c | 2 +-
exalt/src/lib/libexalt_private.c | 2 +-
This patch assumes code in these places were insane and the fix is to remove
one condition check. Most likely this is not true, but there's no automatic fix
for that.
Looking at the patch, it seems that some places should use "x" and "y" vars but
used just one of them and therefore they were caught by coccinelle.
SVN revision: 51666
Revert previous patch generated by badnull.cocci script, and apply the new one.
The main difference is that assert and assert-like functions are not touched
anymore.
SVN revision: 51650
It will show a warning when loading file that may use feature from
newer edje (show up with EINA_LOG_LEVEL=2 in the env).
Please don't forget to increase it when you add feature to edje
file format without breaking backward compatibility.
SVN revision: 51636
The fuction was returning a private type (as
_Edje_Font_Directory_Entry) and an EAPI should *never*
return and private type.
By Fabiano Fidencio
SVN revision: 51615
The current way of including directfb.h makes it hard for people with multiple
versions of DirectFB installed.
This is the correct way to include that header, and it's the way
ecore_directfb does it.
Patch by: Eduardo Felipe <eduardofelipe87@gmail.com>
SVN revision: 51610
that you'd get dirty areas that didnt re-rneder. fixed with nasty hack
- force a full update if anyone in the evas object tree changed maps
from on to off and vice-versa
SVN revision: 51600