On Tue, 24 Jun 2008 09:51:37 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> On Mon, Jun 23, 2008 at 1:14 PM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > 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. :( > > I strongly disagree, see my examples, using that will make your life > much easier. The idea is very simple, the worker thread doesn't even > need a select, it can just sleep on read() and that's it. Ok, you can > do that with pthread_* primitives, but I don't see why. You get images > to process, you send them to the thread, that keeps a "to do" list, > process by priority order. These images (actually the structure that > points to it) will be marked with the priority and the state (todo, > done, canceled, ...) and it will all work well without any locks. > Summary: worker thread just look at some flag, if it's PROCESS then > put the pixels, notify back. No image allocation/free should be done > on the worker thread, thus no locks. i honestly think its much of a muchness. as it stands there is a simple single fd that the threads use pthread constructs to wake it up and write messages to it to wake up the process. with many fd's you need to read one and write to another... as evas only has 1 async fd... so for the work queue going out to the thread - yes, but for incoming back to the process to say "hey - stuff happened - wake up!" we really need just 1... and thus pthread lock stuff around it to avoid it filling with garbage (if the data is large being written and has meaning. right now it isn't - but it may... one day). > Also, giving the use case, I'd avoid locks on images and alloc them on i absolutely agree on this. the fewer locks, the better! > the main thread before requesting it to be loaded, this way no pointer > will change, just the contents of it, then no problem. This will make yup. if just the image data is by workers without locks - this is fine... except for freeing - the main thread can't free the image until workers have stopped filling it... so you need to be able to kill them off reliably before you free. > life much easier for a feature that is just aimed to make application > not block while reads huge images from slow access memory (disk), > avoiding complications on the existing code paths. yes. it is a nice feature. for small images and absolutely necessary images for the ui (eg buttons and widgets) you want to block as the ui is pretty useless without them or with them partially loaded, but the ability to selectively go "this image is probably going to be huge, and i am happy to have it partly or just not displayed at all until its async loaded" is great. i like the whole idea. it just needs to be solid. :) > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [EMAIL PROTECTED] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
