On Fri, 12 Sep 2008 18:13:31 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
gee. and i come to the patch.. a whole chunk of it is in evas already! so nothing to do! yay! > Time to wake up dead old patch :-) > > On Mon, Jun 23, 2008 at 6:14 PM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Wed, 18 Jun 2008 18:53:06 +0200 "Cedric BAIL" <[EMAIL PROTECTED]> > > babbled: > >> 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. > > So updated the patch (It's against the root svn as it also patch > expedite) and added the lock around the surface allocation. > > Deleting the image should not be a problem as it is handle right now > by evas_cache_image_drop. It will remove, with wait if needed, the > image from the queue when the reference goes down to zero. Their is no > need to lock anything around the image in the engine, every thing is > done in evas_cache_image.c. > > I am using since few month and I didn't see any crach with it nor slow > down, so if people don't really mind I can put it in svn (It's > possible to deactivate it at compile time, in which case preload will > act as a synchronous load). > > -- > Cedric BAIL > -- ------------- 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
