2010-03-16

PNG and DOM

Two hopefully invisible changes today, but scream if anything breaks:
  • I've changed the map to generating PNGs by default instead of GIFs. This is to work around a bug in embedded WebKit (seen in the Second Life Viewer 2.0 Beta) where it may not display GIFs correctly.
  • I've rewritten the event handling code for the map to more correctly manage DOM events, in both the W3C and IE models. This is to try and make dragging work correctly in the IE9 Platform Preview (I'll test tomorrow), clean up the code (this was my first interactive web site!), and as a side effect it fixes mouse wheel support in Chrome.
I've tested in IE8, Safari (Win), Firefox 3.6 (Win), Chrome 4 (Win), and Opera 10 (Win). Looks good, but I'm nervous and ready to roll back if anyone sees any issues.
Ω

4 comments:

Joshua Bell said...

And just to confirm, this does work in IE9 and Safari 4 (Mac)

Anonymous said...

I have a collection of URLs for printing sectors to US Letter, and was adding a couple of links to it today.

In doing so, I noticed that the images I produced earlier (10/2/2009) resulted in images (GIF) sized 900 x 1296,
whereas the images I produce today (including links I had worked out and stored earlier) now produce images (PNG) sized 1350 x 1944.

The change to PNG is a good thing, but the change in output size is unfortunate.

An example link I've been using:

http://www.travellermap.com/Poster.aspx?sector=Spinward+Marches&options=2907&scale=48

Before: 900 x 1296
Now: 1350 x 1944

Anonymous said...

Oh, browser version where I saw the changed size is Firefox 3.6.3 on Windows XP SP2.

I think I had an earlier Firefox for the "before" images, not sure what version.

Joshua Bell said...

Weird - the old behavior must have been a bug. The scale is pixels/parsec, so you can easily compute:

width = 32pc * 48px/pc * cos(30) = 1330
height = 40pc * 48px/pc = 1920

The differences (1350-1330 = 20, 1944-1920=24) are due to padding around the edges so hexes aren't cut off.

The 900x1296 number is what you'd expect for scale=32. It's possible that the Poster API didn't used to respect scale and I fixed it. If I have a chance I'll dig into it, but I can't call the current behavior a bug, unless I'm missing something.