I have a project I’m planning which based on kind of an ‘interactive world’ style experience where the browsers viewport moves around to show many different graphic environments, it must all be fluid and no page-to-page breaks. The project is in js/html5/css3
The problem this poses is that the entire ‘world’ will be perhaps 8-15,000 px squared (it also rotates, and has various png alpha overlays on top of it)
I was going to run some tests but there are so many ways to approach this and I’m looking for the most fluid one. My knowledge of the internal workings of browser render engines isn’t great so I thought I’d ask around.
I cant use the ’tiling’ approach which google map uses as it’s not fluid enough (too blocky) also when rotating around it’s going to create headaches do the math-transforms to work out which tiles to load at what angles so here are the 2 choices I have boiled it down to:
(1) The “Huge” image approach
The benefit of this is that once it’s loaded everything is easy, the downside is that it’s going to be huge and I cannot show an incremental preloader as the image queue will essentially be 2 images (overlay and huge img)
(2) Image segments
The benefit is that I can show a preloader with an image queue at 10% increments (10x images)
Question:
is the 2nd approach going to have a more painful overhead on the browser’s rendering engine due to there being 9 separate sets of calculations being done or do browser engines simply see them as one painted area once it’s initially rendered and then update it as a whole? Or each time the dom is changed (rotated etc), the browser has to run the same transform/repaint process 9 times?
Thanks very much.
LOTS of tests later: result: Use a big image, seems to be less for the browser to deal with.