[OpenLayers-Dev] transition sandbox - request for comment

[Pedro Simonetti]

pagameba wrote:
> 
> Eric,
> 
> the sandbox is unchanged, you should be able to try it out.
> 
> http://dev.openlayers.org/sandbox/pagameba/transition/examples/transition.html
> 
> Everything is pretty good except for the animated tiled layer, which  
> suffers from the problems indicated.
> 
> Cheers
> 
> Paul
> 

Hi all,

Sometime ago I was using a technique I'll describe here to resize multiple
HTML 
elements at the same time. This technique relies on relative sizing, so all 
elements that sould be resized must use "em" or "ex" units. The best results 
can be achieved with "em".

I thought that maybe this technique could be used to improve the performance
of 
the zoom animated transition effect, specially in the case when using tiles. 
The current implementation performs changes in "top", "left", "width" and 
"height" properties of each tile on the layer. With a small map viewport the 
performance isn't a problem at all, but with larger viewports, or with
multiple 
layers using this effect, you will clearly perceive the performance
problems.
MY PC is a little bit old, but it isn't slow. I'm using a AMD Semprom 2600+
1256 RAM, NVIDIA GeForce FX 5500, on a Windows XP SP2.  

Another problem of the current implementation, is that sometimes the tiles 
makes some strange resizing and shifting effects. I'm not sure how to
exaclty 
reproduce this, but I think is when you do a zoom in, and right after a zoom
out 
without waiting all tiles to be loaded.

As far as I can see, the "relative sizes technique" will vastly improve the 
performance, specially in tiled maps, or in multi-layered maps. The
performance 
gain occurs because you'll have to change only 3 css properties to resize
and 
reposition all tiles at once. I think that this technique will also fix the 
strange effects issue, because the individual tiles won't be changed.

This technique is a little bit tricky, and will require some modifications
in the style of the generated tiles, but I think the costs/benefits will be 
positive.

======================================
The Relative Sizes Technique Overview
======================================

The trick is use a 10px font-size in the map container. Then, all sizes and 
positions of the container, and the tiles inside of it, must use "em" units.
The 10px is the optimal value because it will easier the convertion to
relative
units. For example, to indicate that the "top" property of the container
will
have a value equivalent to 128px, you'll have to set the value as "12.8em" 
(12.8 * 10 = 128).  

In theory, all relative values of the container's children will be based on
the
container's font-size. But, it seems FF ignores the font-size inheritance
when
the element has a absolute position, and that's the case of the tiles. So'll 
have to explicit inform a "em" value in the tiles. 

Another problem is that Opera seems to have problems when using this
technique 
with "em" values smaller than 1, like 0.5. The workaround is to use a "10em" 
value on the tile's style rule.

So, to allow changing all values at once, you should use a css rule like
this: 

    .div_tile {
      font-size: 10em;
      position: absolute;
    }


Then each tile will be like:

    <div class="div_tile" style="top:0; left:2.56em;">
      <img src="..." class="img_tile" galleryimg="no"/></div>


So, once 1em = 10px, 10em will be equivalent to 100px for the tile measures.
Then, to have a 256px wide tile, you'll have to use a "2.56em" value. To
apply
the same size to all tiles, I've used a css class in the tile images, but
you could use inline css values too.

    <img src="..." class="img_tile" galleryimg="no"/>

Here's the css rule of the tile images:

    /* 1em = 100px --> 2.56em = 256px */
    .img_tile {
      width: 2.56em; 
      height: 2.56em; 
    }

By making this, if you change the "font-size" of the ".div_tile" css rule,
all 
tiles will be resized and repositioned proportionally. The "10em" value 
represents a 100% size, so changing the font-size to "20em" will make a 200% 
zoom, 5em = 50%, 2.5em = 25%, and so on.

After that, the position of the tiles will change, so you'll have to adjust
the
"top" and "left" properties of the container.

This aproach has some problems. First, it is semantically wrong using
font-size
to control elements measures and positions. Second, it will require 
modifications in some parts of OL code (I'm not sure exactly which parts).
Third, I'm not sure about the mathematical precision of this approach when
using cartographic calculations.

But, the improve in performance will be significantly high, allowing using
smooth animated zoom effect with full screen maps and/or with multiple
layers.

Considering that "a demo says more than a thousand line codes", I've made a 
simple example ilustrating this technique. I've declared the values of CSS
in 
the <style> tag, in a real application those values can be inline,
using 
style property inside html tags.

======================================
Example
======================================
Here's a prototype. I'm not using OpenLayers. It's just a test to check the
potential of this approach. This example is very simple but it uses a
timming
based animation technique that skips automatically the frames if the on
slow computers, or when the browser is processing heavy codes.

You can enable/disable an overlay to see how the performance is affected on
multiple layers. The impact in performance isn't big, so I'm estimating that
it will be possible to use this effect at fullscreen with 1 to 2 overlays,
even in older computers.

Of course, this performance will decrease when applied inside the OL 
application, but it worth take a look.  

http://jproton.com.br/sandbox/relative-sizes.html

Note: in the upper right corner there's a DIV that resizes the map when you
hover mouse in it. Again, this is just a test, and I think the performance
of 
this feature can be improved by skiping some frames.

Note2: I'm using document onload event to initialize the example. So,
because
of this, no effects will happens until all images are loaded. Though, this
approach should behave correctly even when the tiles are loading, if the 
images are generated by JavaScipt code. This is not implement in this
example
for simplicity reasons.

======================================
PROS
======================================
  - highly efficient
  - scalable
  - backwards compatibile
  - as far as I could test, it's consistent along different browsers (I've 
    tested with IE6, FF2, and Opera9)
  - will allow factional zooming when dragging the scale control, as the 
    earlier demo of Emanuel:
    http://dev.openlayers.org/sandbox/emanuel/animatedZooming/demo.html  

======================================
CONS
======================================
  - It is semantically wrong using font-size to control measures and
positions
  - Being semantically wrong, the code tends to be less readable, besides
    this can be minimized with comments along the code
  - By using relatives sizes, it means that if the user change the font-size 
    of document, or use a full-page zoom tool, it will resize the map too. 
    But in a near future this will be the normal behaviour of the browsers. 
    Opera 9 already resizes images when changing the page zoom. FF3 too. 
    And IE8 too. The nighly version of Webkit also supports this feature:
    http://www.mozilla.com/en-US/firefox/3.0b5/releasenotes/#whatsnew
   
http://blogs.msdn.com/ie/archive/2008/03/25/internet-explorer-8-and-adaptive-zoom.aspx
    http://webkit.org/blog/165/full-page-zoom/



If you feel insterested in more details about this technique, just ask for 
more info. I'm not describing all details here to not over extend this post.

I don't have much knowledge in cartographic math, so I'll let this part to 
you geo gurus. =)

I hope you find this crazy idea insteresting. =D

my best regards,

Pedro Simonetti.
-- 
View this message in context: http://www.nabble.com/transition-sandbox---request-for-comment-tp14823509p16765822.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.