[Tilesathome] Potential t at h optimization: Re-use the optimized .png image

[Ævar Arnfjörð Bjarmason]

On Thu, Dec 18, 2008 at 11:32 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> 2008/12/18 Ævar Arnfjörð Bjarmason <avarab at gmail.com>
>>
>> On Thu, Dec 18, 2008 at 8:10 PM, Matthias Julius <lists at julius-net.net>
>> wrote:
>> > "Ævar Arnfjörð Bjarmason" <avarab at gmail.com> writes:
>> > I guess you were looking at empty tiles (67 or 69 bytes).  Empty tiles
>> > are not optimized.  In fact, they are never written to disc.  When the
>> > client finds during tile splitting that a tile is empty it throws the
>> > tile away and copies emptyland.png or emptysea.png from the client's
>> > root directory.  Those are actually 1 pixel PNGs with 67 respective 69
>> > bytes size.
>>
>> I should have been clear on that. No they were not empty tiles (I read
>> the tile optimizing code and noticed the empty tile optimization you
>> mention). What I was rendering was a glacial area which 1844,1089 is
>> an example of. In cases of such tiles Tileset.pm will optimize each
>> and every individual z17 tile even though the greater z12 tile
>> consists of only two colors with a thin line running through it, if
>> I've understood it correctly.
>>
>> The map contains many areas where this applies, like lakes, large
>> areas of landuse, large buildings etc.
>
> but this is just applying as long as there are few items already in the
> z12-tile, by the time, when the map is filling up, this optimisation would
> not work.

I find it difficult to imagine a state where the planet would be
filled up in this manner. The majority of it is not urban area and
thus the most of our tiles will be otherwise empty apart from a single
road, a river or a few huts. Even in a hypothetical future state where
the planet has been fully mapped. But this is all awfully speculative
when discussing the code that's in use /now/ :)

> As I have understood the problem though, the bottleneck is the
> server not being able to receive the tiles in time, not the rendering
> process.

The server upload queue is pretty unclogged as far as I can tell. But
in any case optimization of the client and server are separate
problems.