Dave,
I'm amazed that I have never encountered this issue before, but sure
enough, I was able to reproduce it. I did about 6 trials logging in and
out with 7 PDF Viewers in the world. I actually only resized one of the
7 documents. Resizing doesn't seem to be a factor. The rest I left in
their "natural" size. On one trial, all 7 rendered in the correct size.
In several trials, one portrait document came up with a landscape aspect
ratio. In my final trial, two portrait documents came up with the
landscape aspect ratio. I believe that landscape aspect ratio is the
default PDF Viewer window size.
I uploaded an error report to the issue tracker. The only bit of
information I was able to glean from the log is that in the two PDFs
that didn't render properly, there is a cell load time and INACTIVE time
of 0 ms. Here are the log entries for one viewer that loaded correctly
(cell 145) and one that rendered in the incorrect size (cell 144):
> Stats for cell 145 (pdf) PDFViewerCell
> Cell Load Time: 1 ms.
> INACTIVE-time: 1 ms.
> ACTIVE-time: 2438 ms.
> End cell 145
> INFO 10:52:13 AM
> org.jdesktop.wonderland.modules.cellperformance.client.CellPerformanceClientPlugin
> cellStatusChanged
> Stats for cell 144 (pdf) PDFViewerCell
> Cell Load Time: 0 ms.
> INACTIVE-time: 0 ms.
> ACTIVE-time: 1940 ms.
> End cell 144
I'm not sure if that's significant or not. There was also one MTGame
exception in the log:
> WARNING 10:52:15 AM org.jdesktop.mtgame.Renderer processCommitList
> MTGame: Exception Caught in renderer commit:
> javax.media.opengl.GLException: Thread[MTGame
> Renderer,5,javawsApplicationThreadGroup] glGetError() returned the
> following error codes after a call to glTexSubImage2D(<int> 0xDE1,
> <int> 0x0, <int> 0x0, <int> 0x0, <int> 0x280, <int> 0x355, <int>
> 0x1908, <int> 0x1401, <java.nio.Buffer>
> java.nio.DirectByteBuffer[pos=0 lim=2183680 cap=2183680]):
> GL_INVALID_VALUE ( 1281 0x501),
> javax.media.opengl.GLException: Thread[MTGame
> Renderer,5,javawsApplicationThreadGroup] glGetError() returned the
> following error codes after a call to glTexSubImage2D(<int> 0xDE1,
> <int> 0x0, <int> 0x0, <int> 0x0, <int> 0x280, <int> 0x355, <int>
> 0x1908, <int> 0x1401, <java.nio.Buffer>
> java.nio.DirectByteBuffer[pos=0 lim=2183680 cap=2183680]):
> GL_INVALID_VALUE ( 1281 0x501),
> at javax.media.opengl.DebugGL2.checkGLGetError(DebugGL2.java:24811)
> at javax.media.opengl.DebugGL2.glTexSubImage2D(DebugGL2.java:10396)
> at
> com.jme.renderer.jogl.JOGLRenderer.updateTextureSubImage(JOGLRenderer.java:1993)
> at
> com.jmex.awt.swingui.JOGLImageGraphics.update(JOGLImageGraphics.java:186)
> at
> org.jdesktop.wonderland.modules.appbase.client.DrawingSurfaceImageGraphics$UpdateProcessor.commit(DrawingSurfaceImageGraphics.java:338)
> at org.jdesktop.mtgame.Renderer.processCommitList(Renderer.java:1407)
> at org.jdesktop.mtgame.Renderer.run(Renderer.java:960)
> WARNING 10:52:15 AM
> org.jdesktop.wonderland.modules.appbase.client.DrawingSurfaceImageGraphics$UpdateProcessor
> commit
> Trying to draw to texture whose ID hasnt been allocated
This didn't seem obviously related to the problem, but perhaps might be
a clue.
To me, this looks like a timing problem. Perhaps the PDF Viewer is
drawing in the default size before the information about the document
size is received...
If someone has a chance to look into this bug, that would be great.
Thanks,
Nicole.