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