PDF objects randomly resized on client logout -> login

16 views
Skip to first unread message

davenz

unread,
Aug 13, 2013, 5:26:55 AM8/13/13
to openwon...@googlegroups.com
Hi All,

I've just opened the following issue:

http://code.google.com/p/openwonderland/issues/detail?id=322

Has anyone else seen this and is aware of the cause and perhaps a workaround?

Cheers,
Dave

Carlos Rafael Ramirez

unread,
Aug 13, 2013, 9:56:00 AM8/13/13
to openwonderland
Hello,

I think I have seen this issue before but I need to confirm it

Regards


--
You received this message because you are subscribed to the Google Groups "Open Wonderland Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwonderlan...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Nicole Yankelovich

unread,
Aug 13, 2013, 11:23:29 AM8/13/13
to openwon...@googlegroups.com
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.

davenz

unread,
Aug 14, 2013, 8:24:18 AM8/14/13
to openwon...@googlegroups.com, nic...@yankelovich.ws
On Wednesday, August 14, 2013 3:23:29 AM UTC+12, Nicole Yankelovich wrote:

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...


Hi Nicole,

Without knowing the inner workings of Wonderland, this sure looks like the case. I've attached a screengrab made just after logging in as the world is being constructed and objects are appearing. Three PDFs are being drawn (and eventually appear correctly) and the portion that has been successfully drawn is the same height as the right-most PDF (which fails to open at the correct height).

Cheers,
Dave
Wonderland-PDFHeights-5.jpg
Reply all
Reply to author
Forward
0 new messages