hi,
I already fix it, :)
Ya, it's because some blocking on string process logic.
but I still have problem on url image load. I'm using
elm_image_file_set("url"). and this is already asynchronous.
My problem is image always reload when scrolling the list. It's bad for
data charges.
this is my debug results :
1. callback function *content_get* always called when item going realize at
scrolling.
I'm using *genlist item class* with item_style = "full", I need to put
my own edc layout on the item.
2. I'm initialize layout, set all data and call url image inside this
*content_get* callback function.
When scrolling, this makes Evas_Object* for the item recreating and of
course recalling the url image.
I have some idea to cache the item :
3. Inside *content_get* function, I have try to save the Evas_Object* to
hash map after create it,
The goal is if object already exist on map, just return it and not
create and call url again.
*but* when I return Evas_Object* that already save on the map, now it
always crash. T.T
Is there another idea to cache this item?
Thank you
On Tue, Feb 23, 2016 at 6:46 AM, Carsten Haitzler <ti...@rasterman.com>
wrote:
> On Mon, 22 Feb 2016 19:31:50 +0700 leonardus ardyandhita <
> leo4rdy...@gmail.com>
> said:
>
> > Hi, I want to ask about genlist reusable item callback to improvement
> > performance.
> > I need to load multiple image from url on item list. But if I scrolling
> the
> > list, image url always called and makes lack.
> >
> > I have search and I get commit information on elementary git. They say
> > there is new callback function : *Elm_Gen_Item_Reusable_Content_Get_Cb*.
> I
> > think this is can solve my problem. But I can't find on my installed
> tizen
> > sdk. (I have last update tizen sdk 2.4 : rev3).
> >
> > It's is possible to patch this committed code or anyone have some idea to
> > cache the item?
>
> that'll only help if object creation itself is your major overhead. i
> doubt it
> is for you. :) what is the issue? that things are actually slow in that the
> image takes a while to become visible (url download) or the actual image
> header
> load is somehow being slow. but something there is blocking most likely -
> more
> debugging and digging will tell you what.
>
> also note that tizen has historically been between 6 months and like 2.5
> years
> behind upstream development as there is generally a great reluctance to
> upgrade
> so don't expect new features to land in tizen rapidly.
>
> --
> Carsten Haitzler (The Rasterman) <ti...@rasterman.com>
>
_______________________________________________
Application-dev mailing list
Application-dev@lists.tizen.org
https://lists.tizen.org/listinfo/application-dev
