Openmoko Bug #1549: [exposure] want to launch exposure again while it is in the e-illume bar, need 5~10 sec
Openmoko Public Trac
bugs at docs.openmoko.org
Wed Jul 23 02:13:28 CEST 2008
#1549: [exposure] want to launch exposure again while it is in the e-illume bar,
need 5~10 sec
------------------------+---------------------------------------------------
Reporter: wendy_hung | Owner: marek
Type: defect | Status: assigned
Priority: normal | Milestone: ASU
Component: E - Illume | Version:
Severity: normal | Resolution:
Keywords: must have | Blocking:
Blockedby: |
------------------------+---------------------------------------------------
Comment(by raster):
1. i could have the animation happen on mouseup, but it happens to be on
mouse down to provide instant feedback.
2. async - efl is perfectly great at async... it is NOT threadsafe.
everything you have been doing is doing things from threads or from what
effectively acts as a thread (signals handlers interrupt any execution and
jump straight to the handler - just like an preempting of a processor
thread would just remove control on a single-cpu system to another
thread). i have lots of async code. LOTS. you are just chosing to always
do things with threads even though EFL is not threadsafe. BTW - you'd have
the same problem with gtk and qt - if you DIDNT call some sort of "flush"
to flush the x pipeline as you have written a command to a buffer - but
that command isn't write()en to the file descriptor to x until you flush
or it fills up. nothing to do with EFL here - it's to do with using
thread-constructs and not flushing buffers. if the buffers were flushed
it'd work (by sheer luck), but u'd have a thread-bug waiting to happen.
making a system threadsafe is a huge amount of work and is runtime
overhead (all data that could be shared between threads needs locking and
unlocking at all points and it's not an insignificant amount of code that
sooner or later you forget a lock or unlock somewhere, or u happen to
create a deadlock condition). i chose not to do it from early on. btw -
anyone who has done work with gui's and x will tell you not to use signal
handlers to do actual gui work - as they can pretty much destroy the flow
of logic, order of operation, create deadlocks etc. you should always do
as absolutely little as possible in a signal handler and keep it really
simple.
anyway - as for using ecore's handlers, in c it's very simple.
static int my_callback(void *data, int type, void *event_in) {
Ecore_Event_Signal_User *ev = event_in; // get event info
if (ev->number == 2) ecore_evas_activate(data); // if sugusr2 (2 vs 1
for sigusr1)
return 1; // let someone else handle the event if they like - return 1
}
// in init code for canvas
Ecore_Evas *my_ecore_evas_handle; // handle for the canvas window
// assuming you set up the canvas at some point with handle of
my_ecore_evas_handle
Ecore_Event_Handler *handler; // handler handle
handler = ecore_event_handler_add(ECORE_EVENT_SIGNAL_USER, my_callback,
my_ecore_evas_handle);
//... other stuff
// when done - ie dont need handler anymore (shutdown or deletion of
canvas)
ecore_event_handler_del(handler);
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1549#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list