jessyink-team team mailing list archive

[Hannes Hochreiner <hannes@xxxxxxxxxxxxxx>]

Hi Marc:

>         As for the index view problem, I noticed that the index view
>         is not
>         terribly responsive in Firefox. With Opera and Chrome it seems
>         to work
>         better.
> 
> Just tested chrome and it is faster, but it doesn't render "blurred"
> objects properly. It basically renders everything with blur equal to
> 0%. Images are only rendered once. If a view zooms in on an image, it
> becomes pixelated instead of being rerendered. Let's say the image is
> 600x600 pixels, but on the slide only fills 200x200 pixels on the
> screen in the normal slide view. Now you zoom in on the image via the
> view feature. Then the 200x200 is enlarged and interpolated and looks
> pixelated instead of the orginial 600x600 being rerendered for the new
> scaling factor. Firefox does both correctly.
>  

Wow, I didn't know that WebKit had such problems scaling images. I'll
check that out. In general I agree, WebKit based browsers seem more
responsive, but Gecko seems to implement more of the SVG specification.

> 
>         The first version of the index view worked more or less as you
>         described
>         (just without the scroll bar). However, I think the problem
>         might be
>         that on every user interaction the positions of all the slides
>         are
>         recalculated and than the slides are shifted one by one. I
>         know that's
>         how the original code works and I think it is still similar
>         with the
>         current implementation (although we have pages now).
> 
> Why is that needed? If all slides are put on one large page the
> browser can simply move up and down a static page. I also noticed that
> it takes long to render opacity != 100%. Thus it might improve speed
> to simply put a red rectangle around the active slide instead of
> changing the opacity value. Might not look as nice, but would also
> improve visibility of the inactive slides.
> 

Hmm, I was planning on revamping the way modes are implemented anyways,
so this would be the perfect excuse to advance with this work. If the
mode are more modular, it should be easier to experiment with different
implementations of the index sheet. Should it turn out that one is
vastly superior to the others we'll ship that one, otherwise we can also
think about shipping several different implementations.

> 
>         I think it might help to draw all the slides first and than
>         just move
>         the viewport (after implementing the zoom based stuff, I got
>         some
>         experience moving viewports :-)). It should be quite easy then
>         to make
>         it move either a whole page or just a line.
> 
> That would be great! So you basically render one large sheet with all
> slides on and only zoom in on the current one. Might work faster, but
> it might as well be much slower. Depends on how smart the browser is.
> If it renders all slides every time, it will be much slower. If it
> renders once and just zooms, it should work much faster.
>  

Brad Neuberg (of svgweb fame) has suggested that the use of
"suspendRedraw" might improve JessInk's performance, so I am going to
play around with that. I am sure there is still quite a bit we can do to
improve the overall speed.

Cheers,
Hannes