Opened 7 years ago

Last modified 6 years ago

#17870 closed enhancement

OSM Mapnik tiles slow to load (due to ImageIO#read slowness?) — at Initial Version

Reported by: The111 Owned by: team
Priority: normal Milestone:
Component: JMapViewer Version: latest
Keywords: Cc:

Description

I apologize if this is not actually a true JMapViewer bug, but I'd like to at least open a discussion on this, and I'm not sure where else to do so. I contributed to JMapViewer a few times in the past, and it powers my application GPXCreator.

I don't know when exactly it happened, but OSM Mapnik tile loading seems way slower now than it used to be. I traced it down to ImageIO#read. There are lots of Google results for ImageIO being slow at png encoding in general. There are not many solutions, and none of them have helped me. The two most common ones are (1) disable disk caching in ImageIO and (2) install Java Advanced Imaging to leverage native image encoding capabilities on your platform. Again, neither seemed to make a difference.

I'm pretty sure the slowness is not the network IO, but the actual byte encoding. What's weirder is that it wasn't always like this. But looking back through older JMapViewer revisions, it seems ImageIO.read was always there. And ImageIO is not so slow for other tile sources, even ones with larger byte payloads like Bing sat images (which are admittedly jpg, not png). So, why were Mapnik tiles faster to encode in the past?
Has OSM changed their data format returned for HTTP requests, such that the encoding load is higher?

Or is something on my machine to blame? I did recently reimage my desktop with Win10. Can anybody else confirm that OSM Mapnik tiles seem far slower to load than the other sources, and that the slowness is not network IO?

As a sidenote, just as an experiment I even locally tried replacing ImageIO with Apache Commons Imaging, and it is equally slow. :-(

Change History (0)

Note: See TracTickets for help on using tickets.