Can someone commit to svn? On Wed, Nov 2, 2011 at 12:39 PM, Kim Yunhan <spb...@gmail.com> wrote:
> On Tue, Nov 1, 2011 at 11:59 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > >> Hi, >> >> On Tue, Nov 1, 2011 at 10:11 AM, Kim Yunhan <spb...@gmail.com> wrote: >> > Currently, elm_map requests all visible map image tile to map server at >> the >> > same time. >> > If the scene is turned off while panning or zooming, it will be aborted >> on >> > HTTP requests. >> > But it already sent to map server, and it already made useless HTTP >> > connections. >> > So if you pan scrolling quickly, elm_map try to download and abort too >> many >> > HTTP >> > connections repeatedly. >> > >> > If you have stable and high-throughput data connection, it doesn't >> matter >> > on your side. >> > However map server will get high load, It is sufficient reason to block >> > you. >> > In another case, if you have poor data connection such as 3G >> connection, it >> > has less >> > throughput and it causes delay of downloading. And finally, the device >> is >> > as full as >> > HTTP connections even you already aborted. It makes low-performance >> issue on >> > your device. >> > >> > I wrote a patch for solving this situation. >> > The idea is simple. >> > >> > 1. I limited number of maximum HTTP request on elm_map side. >> > 2. If maximum HTTP request is exceed, keep requests on Eina_List. >> > 3. If each image downloading is completed, try to download recent >> request. >> > (Because it has strong possibility for your screen) >> > 4. At the same time, invisible request will be removed. >> > (It doesn't make HTTP connection yet) >> > >> > I tested many times on my desktop and device. >> > It works for me. And elm_map's performance is improved appreciably on 3G >> > connections. >> > >> > Please review this patch. >> >> I like the overall idea of this patch. It's simple, the patch is clean >> and easy to understand, so I have nothing about pushing it in svn. >> I have still a few question, did you investigate if it was possible >> with curl to limit the number of simultaneous request to the server >> and reuse the same connection ? If that's possible, it would be nice >> to enable that at ecore_con_url level. If not, maybe it make sense to >> implement the idea in ecore_con_url directly for EFL 1.2. >> -- >> Cedric BAIL >> >> > First, elm_map should manage download list because of case 3 that > it was written in previous mail. In general, download queue is implemented > as FIFO (First In First Out). But my elm_map's download queue is > processed as LIFO (Last In Last Out). It is not a general case, I think. > > Second, I already investigated libcurl's persistence connection > management. But ecore_con_url doesn't use persistence connection. > If ecore_con_url want to use this feature, ecore_con_url should reuse > libcurl's curl handler. However current ecore_con_url's implementation > is not follow the licurl's rule. It should be improved. > > I think that this issue should be fixed up with mixing these 2 > approaches. So first step is fixed up in elm_map that it was written > in my patch. And ecore_con_url should be improved by reusing curl > handler. I'll try to fix up ecore_con_url further on. > > Thank your for review. :-) > > > >> ------------------------------------------------------------------------------ >> RSA® Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
