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