Clobbered URLs / Lazy Tiles

[bratliff]

The group interface is clobbering URLs. The following link is an
example:

www.polyarc.us/sparse

Tile server reliability seems to have deteriorated recently. Some
tiles never arrive. Switching from/to the same zoom level does not
force reloading. Examining the DOM, the tile slot contains a
"transparent.png" place holder rather than an actual tile image. The
only way to load the tile is to reload the application.

Perhaps the optimizer is being a bit too clever. If the API thinks
the tile is already loaded, it will not attempt to load it again.
Well, I believe it is a horrible idea. If the tile is already loaded,
it will be served quickly enough from the browser cache. If the tile
never arrived, it ought to be requested again. Every zoom change
ought to reload every tile. A slight delay is preferrable to an
incomplete map.

It is unclear why "transparent.png" is even being used. If it is to
disguise progressive rendering, it can be achieved in the onload/
onerror event handlers with "this.style.display" or
"this.style.visibility". The use of a "background-image" is another
option.

A "watchdog" thread might improve reliability. Periodically, it could
look for lazy tiles. If a tile has exceeded a resonable waiting
period, the request could be reissued.

this.src=this.src;

will do the trick.

[jjkaye]

I'm having the same issue with the GMap3 API in FF 3.5.5 (appears to
be working Safari)

http://aialosangeles.org/

Can anyone investigate this?

-j.j.

[Ben Appleton]

On Wed, Dec 2, 2009 at 2:54 AM, bratliff <brat...@umich.edu> wrote:

The group interface is clobbering URLs.

What is a "group interface"?

 

 The following link is an
example:

   www.polyarc.us/sparse

Tile server reliability seems to have deteriorated recently.  Some
tiles never arrive.

This would be a serious issue.  I have loaded your site in FF3.5.5/WinXP and panned around for a while.  I wasn't able to replicate the issue you describe even after loading hundreds of tiles.  Which browser are you using?

 

 Switching from/to the same zoom level does not
force reloading.

If tiles load as expected, there should be no need to forcibly reload.

 

 Examining the DOM, the tile slot contains a
"transparent.png" place holder rather than an actual tile image.  The
only way to load the tile is to reload the application.

Thanks for the info: that seems to imply the tile 'onload' never fired.  I'm not able to replicate this issue locally (perhaps I have a high bandwidth or reliable connection).  If you could grab a screenshot and/or HTTP trace showing that tiles load late or never, that would be really helpful.

 

Perhaps the optimizer is being a bit too clever.  If the API thinks
the tile is already loaded, it will not attempt to load it again.
Well, I believe it is a horrible idea.  If the tile is already loaded,
it will be served quickly enough from the browser cache.  If the tile
never arrived, it ought to be requested again.  Every zoom change
ought to reload every tile.  A slight delay is preferrable to an
incomplete map.

It is unclear why "transparent.png" is even being used.  If it is to
disguise progressive rendering, it can be achieved in the onload/
onerror event handlers with "this.style.display" or
"this.style.visibility".  The use of a "background-image" is another
option.

A "watchdog" thread might improve reliability.  Periodically, it could
look for lazy tiles.  If a tile has exceeded a resonable waiting
period, the request could be reissued.

   this.src=this.src;

will do the trick.

--

You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Ben Appleton]

On Wed, Dec 2, 2009 at 11:03 AM, Ben Appleton <appl...@google.com> wrote:

On Wed, Dec 2, 2009 at 2:54 AM, bratliff <brat...@umich.edu> wrote:

The group interface is clobbering URLs.

What is a "group interface"?

Oh, sorry I misunderstood: you mean that the Google Groups user interface is destroying URLs that you paste into threads?

[bratliff]

On Dec 2, 12:07 am, Ben Appleton <apple...@google.com> wrote:
> On Wed, Dec 2, 2009 at 11:03 AM, Ben Appleton <apple...@google.com> wrote:

> > On Wed, Dec 2, 2009 at 2:54 AM, bratliff <bratl...@umich.edu> wrote:
>
> >> The group interface is clobbering URLs.
>
> > What is a "group interface"?
>
> Oh, sorry I misunderstood: you mean that the Google Groups user interface is
> destroying URLs that you paste into threads?

Yes. I did not know what else to call it.

It appears to be happening just to my links. It looks like a
redirector is being used for tracking purposes. It attempts to
redirect to a URL which itself is redirected to another host.
Apparently, double redirection fails. I suspect it will work if I use
the real URL. It means a lot of old links of mine will not work. It
means I cannot easily move to another ISP.

With regard to lazy tiles, a screen shot is not very useful. Imagine
a map with a few big gray squares in place of tiles. Imagine staring
at the map for five minutes with no change. In Firefox 2.0, click on
Tools/Page Info/Media. Scattered among the real tile URLs are several
occurrances of "whatever.transparent.png".

The frustrating thing is not being able to repair it legally. If I
could just reset the "src" property, I could fix it but the "src"
property still points to "whatever.transparent.png". If I could do a
"map.setZoom(map.getZoom())", I could fix it but your optimizer
ignores it & does nothing. Please add something to the API to force a
reload of all tiles even if the API thinks all tiles are already
loaded properly.

You guys ought to set up a "mine sweeper" on a long delay. If it
actually does fire because no "onload" event handler has reset it for
a full minute, it ought to cycle through all in progress images. If
it encounters any "whatever.transparent.png" images, it would attempt
a reload. It it encounters all "whatever.transparent.png" images, it
would assume an unsupported zoom level.

For what it is worth, I built a little toy tile stitcher a few years
ago. It does not play games with transparent place holder files. It
just toggles the "style.display" property in the "onload" event
handler. It also manages a prioritized queue to prevent dozens of
tile requests from occurring simultaneously. It is very reliable with
your tiles. It is very fast with your tiles. It enables a user to
change pan/zoom directions quickly without ever having more than four
pending requests in the pipline. Out of view tiles are quickly
expunged from the queue. In flight tiles are not aborted due to
browser reliability & potential backtracking. I use it to run full
screen flight simulation with aerial tiles.

[Daniel Lee]

FYI, our attempt to fix this problem is now live. Changelog update is
coming, but in the meantime, please report back if you're still
experiencing tile issues.

[bratliff]

On Dec 11, 1:37 am, Daniel Lee <daniel...@google.com> wrote:
> FYI, our attempt to fix this problem is now live. Changelog update is
> coming, but in the meantime, please report back if you're still
> experiencing tile issues.

The "Clobbered URLs" issue can be resolved by adding "http://" to the
URL. Previously, a link did not require it.

The "Lazy Tiles" issue seems to have improved. I still see "late
arrivals" but if I wait a minute, the tiles usually appear. I suspect
a flaky router along the path is causing it. Perhaps the server can
retry the request if it does not receive a timely acknowledgement.