On Wed, 18 Jun 2008 18:53:06 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
> Hi, > > Here is a patch that add support for background preloading of a data > image. You can now, if you know what you do, ask evas to load the data > of an image in memory before it is displayed (look at the sample code > for expedite). > > The code is quite simple, we have now a work queue where we add all > the Image_Entry we need to preload. They are processed one after the > other in another thread. When it's done, it notify evas main thread > with evas async API and work on the next Image_Entry. > > This means that we now require that engine surface creation and > loader should be thread safe. It's currently the case for all the > engine I know something about, so this should not break anything. > Anyway this code is optionnal and could be completely unactivated in a > per engine basis or globally. > > As always have fun reviewing this patch. hmmm - i like the idea - yes. missing cache surface alloc mutex :( that should not be hard to add - a little bit of extra code. also missing Evas.h prototype for exporting the preload call. looks like most engines have the calls supported. the problem is what to do out fd'with the locks on alloc. as such it is unlikely to cause problems as it stands in the patch - but may if the alloc happens while deleting/freeing an image. the images themselves all need locks now for anything accessing them. for other comments. i dont think we need to worry about fd's - the async fd is wrapped already. we dont need fd's internally in the async loader backend as it is by nature thread-aware and thus can and will use pthread primtitives and can use them for internal syncronisation or anything it likes. look at the evas pipe thread code - it doesnt use any fd's because it doesnt need to use them. there is no NEED for it to wake up select. i dont think u need to worry about this. we need to worry about the locks now needed on all images as the surface alloc is async to the mainloop. mainloop may do other things (like begin to use the image for other things while the async thread is allocing and hasnt been cancelled yet). the safe solution as above is locks on all images - but this is kind of ugly. i'd rather have this be less invasive in this department. but this means all operations on images need a mutex lock/unlock. :( -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
