On Wed, Jun 18, 2008 at 7:44 PM, Gustavo Sverzut Barbieri
<[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 1:53 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote:
>> 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.
>
> so here it goes:
>
> configure.in: $build_async_preload should depend on async_events, no?

You are right.

> -   EAPI Evas_Bool        evas_async_events_put             (void *target,
> Evas_Callback_Type type, void *event_info, void (*func)(void *target,
> Evas_Callback_Type type, void *event_info));
> +   EAPI Evas_Bool        evas_async_events_put             (const void
> *target, Evas_Callback_Type type, void *event_info, void (*func)(void
> *target, Evas_Callback_Type type, void *event_info));

> you made target const, but not in the callback... this is strange.

Well in most place in the EFL,  when a function doesn't free/modify an
object we mark it as const even if some outside fonction could modify
it. I don't have a hard opinion on this subject, so if you prefer I
will remove the const stuff.

> As for the rest of the code. I told you at IRC, but you insist to not
> listen to me, so the review is: do not use mutex or cond, use a pipe!

Lol ! Sorry but the code was already written, my problem was just
thread priority at that time :-) So I didn't want to rewrite it as I
already have something working.

And regarding pipe, I just see one problem using them, we will not be
able to latter add the possibility to reprioritise the loading of
image. This could be usefull in the case of an image viewer I believe.
I also don't understand why you dislike so much mutex and cond stuff.
-- 
Cedric BAIL

-------------------------------------------------------------------------
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

Reply via email to