Jorge wrote:
> 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
I wish I could suggest anything concrete here, but unfortunately I really
don't know what might be a good way to proceed. :( If you and Cedric and Hisham
and others have something along the lines of using evoak for this (maybe with
the code being in evas or partly in there or whatever), then that would be
great.
____________________________________________________________
Beauty Product Reviews
Read Unbiased Beauty Product Reviews and Join Our Product Review Team!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UvsYF23rCNEbCuYtmgP8m9WavIygdeqxgKyEnGXVByFGzf/
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
