Hi Artur,
When indexed geometry change and USE_COORD_INDEX_ONLY
is not used. The geometry will unindex first before
passing down since current OGL library don't support
individual index for different color/vertex/normal etc.
From the source of of CylinderSkin the Color and
Vertex index are the same. After adding the flag
i.e.
geom = quad = new IndexedQuadArray(16*20,
QuadArray.COORDINATES|
QuadArray.COLOR_3|
QuadArray.USE_COORD_INDEX_ONLY|
QuadArray.BY_REFERENCE,4*16*19);
IndexedGeometryArrayRetained.cloneNonIndexedGeometry
will not invoke and the stuttering issues is
disappear.
Thanks.
- Kelvin
-------------
Java 3D Team
Sun Microsystems Inc.
>Date: Tue, 19 Mar 2002 18:23:40 +0100
>From: Artur Biesiadowski <[EMAIL PROTECTED]>
>Subject: Re: [JAVA3D] Stuttering issues in Java3d/Java?
>To: [EMAIL PROTECTED]
>MIME-version: 1.0
>Content-transfer-encoding: 7bit
>X-Accept-Language: en-us, en
>Delivered-to: [EMAIL PROTECTED]
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9)
Gecko/20020311
>
>Chris Forrester wrote:
>[...]
> > Running that program, I get a noticable lag every half-second.
>
>Always, in such case, run program with -verbose:gc.
>
>[GC 1573K->1569K(2568K), 0.0043237 secs]
>[GC 2052K->2037K(2568K), 0.0044562 secs]
>[Full GC 2037K->1089K(2568K), 0.1187422 secs]
>[GC 1572K->1569K(2568K), 0.0041880 secs]
>[GC 2052K->2037K(2568K), 0.0044570 secs]
>[Full GC 2037K->1089K(2568K), 0.1191352 secs]
>[GC 1572K->1569K(2568K), 0.0041846 secs]
>[GC 2052K->2037K(2568K), 0.0047235 secs]
>[Full GC 2037K->1089K(2568K), 0.1225102 secs]
>[GC 1572K->1569K(2568K), 0.0041930 secs]
>[GC 2052K->2037K(2568K), 0.0043799 secs]
>[Full GC 2037K->1089K(2568K), 0.1186064 secs]
>
>(I have allowed myself posting it as plain text, not as screenshot of
>cmd.exe - I hope everybody will forgive me...)
>
>Anyway, full GC happens every second or even more frequently, stopping
>the world for 0.12s, which is very noticeable. Problem seems to lie
>inside program - it seems to allocate a LOT of garbage.
>
>Easiest check is to run program with -Xrunhprof:heap=all,depth=10 and
>stop after some time. Then look at table and check where is the biggest
>difference between life and allocated data (this shows garbage - just
>amount of data tells nothing, because it can be static and not a
>problem). Here we find offender at first line:
> percent live alloc'ed stack class
> rank self accum bytes objs bytes objs trace name
> 1 47.20% 47.20% 1021920 30 14170624 416 7718 [F
>also interesting is
> 13 0.69% 65.82% 15000 250 605280 262 1 [I
>and
> 17 0.57% 68.31% 12240 30 169728 416 7696
>javax.media.j3d.QuadArrayRetained
>
>With 13 we are out of luck (stack trace 1 is unknown), but rest shows
>clearly what is the problem:
>
>TRACE 7718:
>javax.media.j3d.GeometryArrayRetained.createGeometryArrayData(GeometryArrayReta
ined.java:1422)
>javax.media.j3d.IndexedGeometryArrayRetained.cloneNonIndexedGeometry(IndexedGeo
metryArrayRetained.java:97)
>javax.media.j3d.GeometryArrayRetained.updateMirrorGeometry(GeometryArrayRetaine
d.java:9954)
>javax.media.j3d.RenderingAttributesStructure.updateObject(RenderingAttributesSt
ructure.java:185)
>javax.media.j3d.MasterControl.updateMirrorObjects(MasterControl.java:2565)
>javax.media.j3d.MasterControl.runMonitor(MasterControl.java:3230)
>javax.media.j3d.MasterControl.doWork(MasterControl.java:2817)
>javax.media.j3d.MasterControlThread.run(MasterControlThread.java:28)
>
>TRACE 7696:
>
javax.media.j3d.IndexedGeometryArrayRetained.loneNonIndexedcGeometry(IndexedGeom
etryArrayRetained.java:91)
>javax.media.j3d.GeometryArrayRetained.updateMirrorGeometry(GeometryArrayRetaine
d.java:9954)
>javax.media.j3d.RenderingAttributesStructure.updateObject(RenderingAttributesSt
ructure.java:185)
>javax.media.j3d.MasterControl.updateMirrorObjects(MasterControl.java:2565)
>javax.media.j3d.MasterControl.runMonitor(MasterControl.java:3230)
>javax.media.j3d.MasterControl.doWork(MasterControl.java:2817)
>javax.media.j3d.MasterControlThread.run(MasterControlThread.java:28)
>
>
>Data is not allocated in program, but in java3d. It has to expand
>indexed geometry before feeding it to renderer. For some reason, it
>seems to create a lot of temporary structures there (probably a design
>decision, because one of reasons to use indexed geometry is to save
>memory - would be bad if java3d would keep full expanded copy for all
>the time).
>
>Solution:
>a) Use java3d 1.3, single index for all types of vertex data and hope it
>will be accelerated without expanding.
>b) Do not use indexed geometry.
>
>I wonder from where [13] garbage comes - it seems to be only few very
>big int[] objects... Anyway, I also suspect indices.
>
>Artur
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff JAVA3D-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
