On Wed, Jun 25, 2008 at 2:29 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Gustavo wrote: > >> On Tue, Jun 24, 2008 at 2:40 PM, Hisham Mardam Bey >> <[EMAIL PROTECTED]> wrote: >> >>> On Tue, Jun 24, 2008 at 12:55 PM, Gustavo Sverzut Barbieri >>> <[EMAIL PROTECTED]> wrote: >>> >>>> On Tue, Jun 24, 2008 at 1:46 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: >>>> >>>>> Gustavo has a point here. This kind of thing can easily get out of >>>>> hand >>>>> in complexity and obscurity.. for what kinds of uses, effects, ....? >>>>> I wonder if it might not be 'better' to have such (sync and/or async) >>>>> image loading done by a separate server which would fill or hand out >>>>> image data >>>>> via some ipc mechanism? Then the server can do quite few more things than >>>>> even >>>>> evas does now such as take full paths into account, monitor src file >>>>> changes, >>>>> give better file info, error reporting, progress reporting, etc. And it >>>>> can >>>>> implement things via whatever means might be best, and possibly be useful >>>>> to >>>>> many other apps/libs as well. >>>>> >>>> This is out of Evas scope, at least this scope. You can implement such >>>> things for things that are usually shared among lots of apps (ie: >>>> Open/Save/Close icons), just have the main app to do that and share >>>> the memory (shmem or equivalent) and set the pointer of evas image >>>> data. >>>> >>> Its not actually - only yesterday raster and I were talking about it >>> (sharing image and font cache across all apps and libs using Evas), >>> and this idea slots in nicely to fill that gap and to asynchronously >>> load data. >>> >> >> As I said, I like the idea, but I don't see this happening in Evas >> itself, as it barely knows about system, how could it do something as >> this? Ecore_Evas or more higher level (Evoak) is fine. >> > > Frankly, I would rather not see any of this async image loading code > in evas itself. In fact, even the various image loaders and cache mechanism > are not really part of the 'canvas' functionality that is its real meat.. > Most, if not all, of that could be placed outside of it, and if those aspects > can be made even more refined, more useful, and also available to more than > just evas, then so much the better.
I agree, the async image loading fit better on an outside lib/server than in evas itself, more optimizations can be done 'easily' as what hisham has pointed out: shm across different evas based apps (share fonts, images); this ideas has been partially coded already, but of course evas needs some concept of this to interact correctly with this daemon. > > > ____________________________________________________________ > Beauty Advice Just Got a Makeover > Read reviews about the beauty products you have always wanted to try > http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7Uzus4peHhT382X7aG1eJUSzSN1rnGt7DpBIYeI2Cy4VIrW/ > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
