I once did a comparision based on a quake3-level-benchmark-application that someone ported to Xith, jME and Java3D. At that time, Java3D was the fastest, jME came behind it and Xith was the slowest by far (so much for tuned Java3D...). jPCT was somewhere around JME's performance, albeit i've to admit that the comparision wasn't a fair one because all the others used the BSP-information from the quake3-fileformat and the jPCT version used octrees. If this is good or bad for jPCT compared to the others is another question.
However, all engines have evolved since then, including jPCT. So this test may be no longer valid...i don't know.
To understand jPCT's advantages and its drawbacks, one has to understand the way it works which is fundamentally different from the others. In all other engines, the rendered "primitives" are objects, i.e. if you have a cube, you can assign ONE texture to each stage, set other attributes like transparency and stuff and when it comes to rendering, the object's properties are evaluated, the texture stages are set up accordingly and the cube is rendered as a whole using a vertex buffer or something like that. jPCT brakes objects down into triangles. If only one side (i.e. two triangles) of the cube is visible, only these triangles will be send to the card, not the whole cube. The drawback is, that jPCT does a lot of things in software while the other engines can do this hardware. Or in other words: Where other engines stop processing the geometry themselves and give up control to the graphics card, jPCT's pipeline continues in software. The point where it calls the hardware for support is simply later.
This can be slower for high polygon scenes, which is why i'm always claiming that jPCT isn't a real "polygon pusher". The cool thing with this approach is, that it simplyfies a lot of things for the developer. Where other engines allow one texture per stage and object, jPCT doesn't care. You can assign 1000 textures to one object wildly mixed through all texture stages. You can add and remove stages from single polygons at runtime. If you want to add 20 texture layers to a single polygon if something has hit the polygon, you can easily do it. You can't do that in any other engine. You can use different blending modes on different stages with different textures per polygon on a single object. jPCT will always try to optimize what you've done (it may fail sometimes, but it tries its very best...) to give you the best performance possible out of the mess that you've created...
. Another thing made possible by this approach is, that you can use the normal GLRenderer as well as the AWTGLRenderer in the same way. You don't have to care about threads or put every jPCT related command into a gameloop-construction like you've to do in jME (IIRC).
