Re: Draft document-rendering tiling API to be called from viewer apps

> >        IMHO the decision to render just squares prolly complicates the
> > situation un-necessarily.
>
> Sure, but on the other hand it makes it simpler in that we don't need
> to figure out the aspect ratio of each page (they can be different)
> beforehand.
>
> BTW, I didn't mention in the IDL, but I did think that the not only
> would it be a square, but also the side of the square would be a
> power-of-two. Presumably you also want power-of-two for each side?

I haven't experimented but I've heard that not using power-of-two lengths
is seriously detrimental to performance. Considering we'll be using lots of
resources to begin I think we should make every reasonable optimisation .
Also, in this arrangement, It would be nice to have the dimensions of the
"document" area of the texture. Then if the rest of the bitmap is fully
transparent and the plane is too we can render a "page" alone and keep
track of dimensions.

My main concern with all this is in fact dealing with user interaction i.e.
mapping measurements in pixels to OpenGL coordinates. This is more of a
problem for editing, though.

Also, are we intending to have continuous scroll documents ( with all the
pages available via scroll - like most desktop applications ) or would we
be happy to have users flick (or otherwise) through pages. I think the
latter would make it easier to manage resources for large documents.

Iain.