Specifically:
1) Only rotate print output for PostScript, not PDF.
2) Rotate in the correct direction for PostScript.
3) Set the %%Orientation comment correctly.
FrameLayerBuilder::BuildContainerLayerFor takes responsibility for resolution scaling. The ContainerParameters
passed in are added to any transform requested. Then we extract the scale part of the transform, round the scale
up to the nearest power of two if the transform may be actively animated (so we don't have to redraw layer contents
constantly), pass that scale down to be applied by each child and set the residual transform on the ContainerLayer.
For child layers built via BuildLayer, we just pass the requested scale factor in via the ContainerParameters.
If the returned layer is a ContainerLayer then BuildLayer is guaranteed to have already done necessary scaling.
If the returned layer is not a ContainerLayer then we apply the scale ourselves by adding the scale to the
child layer's transform.
For child ThebesLayers containing non-layer display items, we scale the drawing of those display items so that
the child ThebesLayers are simply larger or smaller (larger or smaller visible regions).
We have to scale all visible rects, clip rects etc that are in the coordinates of ThebesLayers or the parent
ContainerLayer. To keep things simple we do this whenever we convert from appunits to integer layer coordinates.
When a ThebesLayer's resolution changes we need to rerender the whole thing.
nsDisplayList::PaintForFrame needs to respect the presshell's resolution setting. We do that by building a layer tree
with a ContainerParameters requesting a scale up by the presshell resolution; once that layer tree is built, we
adjust the root layer transform to scale back down by the resolution.
See the glXDestroyContext man page:
If GLX rendering context ctx is not current to any thread,
glXDestroyContext destroys it immediately. Otherwise, ctx is destroyed
when it becomes not current to any thread. In either case, the resource ID
referenced by ctx is freed immediately.
In other words, if we want glXDestroyContext to have the well-defined semantics
of destroying the context before future X commands take effect, we must first
release the GL context before calling it. We were failing to do that, but we
were destroying the drawable immediately after that call, and as a result, the
context was outliving its underlying drawable. This eventually resulted in
X_GLXMakeCurrent: GLXBadContextTag X errors on subsequent glXMakeCurrent calls.
