Image tiles not loading in firefox

[Mqrius]

I have this problem mainly in firefox, but also in chrome on somewhat slower connections;

Occasionally, it fails to load or show tiles on my custom map.

To reproduce:

Go to http://havenmap.student.utwente.nl/Preview/?x=22.76&y=0.26&zoom=8&map=1&quiet=false

Wait for the images to load. If there are holes, then there's the problem.

If there are no holes, zoom in 1 time, to maximum zoom. On maximum zoom, I serve the images as pngs, so they are roughly 5 times as big (in bytes). On firefox, I get many many holes. Zooming out and then in again fixes some of the holes (due to caching I guess)

I've read around a bit, and this problem seemed to have popped up on the original google maps a few years ago, but I'm not sure if the problems are related.

Any idea what the problem could be?

[Chris Broadfoot]

Looks like some of your tiles are returning back from the server as 204 No Content.

eg: http://havenmap.student.utwente.nl/Preview/tile.php?x=30&y=-5&map=1&zoom=8

Doesn't appear to be a Maps API issue, but rather something wrong with your request to tile.php

Chris

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

[Mqrius]

Ah yes, when I have no tile available, I reply with a 204. I don't know if this is the proper way to handle this, but it is not the problem.

To prove that, go to this link:

http://havenmap.student.utwente.nl/Preview/?x=14&y=9&zoom=9

There are no 204s from tile.php, yet there are holes in the map...

http://havenmap.student.utwente.nl/Preview/?x=14.36&y=9.4&zoom=9&map=1&quiet=false

[Mqrius]

The problem still exists. Does anyone have any idea why?

[Esa]

On Nov 16, 8:31 am, Mqrius <nuntius.ma...@gmail.com> wrote:
> The problem still exists.

I can see holes with FF. Using Firebug, I cannot see those tiles even
requested.

> Does anyone have any idea why?

Maybe the the small tilesize (100px, 100px) causes just too many http
requests at a time.

If you have a look at Google's tile requests, they are spread to more
than one server. Browsers like it. You could try similar arrangement.
Copy your tileset to a different server name and rewrite your
getTileUrl() to fetch every second tile from the second server.

[Mqrius]

I don't really have another server handy. I suppose I could create another domain name which would be actually the same computer, but I'm not sure if that would have the desired effect...

[Andrew Leach]

It probably would. The different "servers" Google uses
"mt0.google.com", "mt1." etc point to the same load-balanced cluster.

Browsers have a maximum number of requests they can open at once to a
server -- I can't remember the details -- and this is a standard trick
for increasing the number of connections a browser can make.

[Chad Killingsworth]

HTTP specs say 2 simultaneous connections per server. Most web
browsers exceed that but there is still a rather small limit to
simultaneous connections. See http://code.google.com/speed/page-speed/docs/rtt.html#ParallelizeDownloads

Chad Killingsworth

On Nov 16, 7:34 am, Andrew Leach <andrew.leac...@gmail.com> wrote:

[Mqrius]

Alright, so multiple cnames and larger tiles should reduce this problem. I can muster up 3 different domain names to serve my tiles from, and will see if that helps (once my request is registered).

One thing that seems weird to me, though, is that the tiles just "aren't there". I don't see any timeout errors or not founds or something in firefox, it just doesn't show up... Any idea why?

[Rossko]

> One thing that seems weird to me, though, is that the tiles
> just "aren't there". I don't see any timeout errors or not founds or
> something in firefox, it just doesn't show up... Any idea why?

We don't know how the API manages its queue for tile image requests ;
we can guess that it _could_ discard excess requests e.g. for
"padding" tiles that are out of actual view. Algorithms for that
would probably be based on 256px tile sizes, so it _might_ give
unexpected results at 100px

[Mqrius]

Well, I could be wrong, but that doesn't seem to be the problem here. The dropped tiles seem distributed randomly, and not the same every time the same location is loaded, which I would expect if your explanation was the case. Also, I do suppose different tilesizes are fully supported if there is an option to define the tilesize...