Menu
▾
▴
gl4java-usergroup
|
From: <NM...@th...> - 2001-12-10 20:31:17
|
Hi,
Regarding your first issue...
Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " .
For some reason the GLCanvas uses the left hand rule and the GLJPanel is
using the right hand rule. So when drawing scenes get kind of turned
around. I don't know whether this is documented anywhere, but I think it
should be added if it isn't. Or the "quirk" should maybe be looked at being
corrected so the two components are consistent.
As for your second issue, sorry, I am unable to help you out.
Hope that helps,
Noah
Toshiyuki Ishimura / 石村 俊幸
<is...@mi...> To: <gl4...@li...>
Sent by: cc:
gl4...@li...urc Subject: [gl4java-usergroup] GLJPanel bug?
eforge.net
12/10/2001 01:25 PM
I have a question and a wish.
I'm making a trial the GLJPanel.
I declared a Panel class extended from the GLJPanel and
transplanted from a GLCanvas working correctly to the Panel.
However, the Panel shows the reverse view every time.
I try to modify the GLJPanel class as follows:
--- original code ---
if(!customOffScrnSize)
gr.drawImage(offImage, 0, 0, this);
else {
size=super.getSize();
gr.drawImage(offImage, 0, 0, size.width, size.height, this);
}
--- original code ---
--- modified code ---
Graphics2D gr2d = (Graphics2D) gr;
if(!customOffScrnSize) {
gr2d.drawImage(offImage,
new AffineTransform(1, 0, 0, -1, 0, offImage.getHeight()),
this);
}
else {
size=super.getSize();
gr2d.drawImage(offImage,
new AffineTransform(1, 0, 0, -1, 0, offImage.getHeight()),
this);
}
--- modified code ---
After this modification, I get the same result between
the GLCanvas and the GLJPanel.
Does this GLJPanel behavior keep GL4Java's specification?
Also, I wish to speed up the GLJPanel with new API in JDK1.4
(e.g. the VolatileImage class and the java.nio package).
GL4Java developers have any plan at this point?
I'm sorry about my strange english.
Regards,
--
Toshiyuki Ishimura
is...@mi...
_______________________________________________
gl4java-usergroup mailing list
gl4...@li...
https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
|
|
From: Kenneth B. R. <kbr...@al...> - 2001-12-11 05:09:38
|
> Also, I wish to speed up the GLJPanel with new API in JDK1.4 > (e.g. the VolatileImage class and the java.nio package). > GL4Java developers have any plan at this point? I think the way to get more speed out of GLJPanel is to avoid the pixel copy that is occurring now, by keeping track of where the GLJPanel is within the component hierarchy, clipping the OpenGL rendering region appropriately, and drawing directly to the heavyweight component to take advantage of hardware acceleration. This won't work if the component is partially occluded, but that rarely happens and the system could revert back to the current pixel copy in that case. I'm pretty sure this technique was used in the now-defunct Magician Java binding for OpenGL and is discussed in the author's book: http://www.symbolstone.org/technology/java/nmbook/ |
|
From: Sven G. <sgo...@ja...> - 2001-12-11 05:31:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 11 December 2001 06:09, Kenneth B. Russell wrote: > > I think the way to get more speed out of GLJPanel is to avoid the > pixel copy that is occurring now, by keeping track of where the > GLJPanel is within the component hierarchy, clipping the OpenGL > rendering region appropriately, and drawing directly to the > heavyweight component to take advantage of hardware acceleration. > This won't work if the component is partially occluded, but that > rarely happens and the system could revert back to the current > pixel copy in that case. > > I'm pretty sure this technique was used in the now-defunct > Magician Java binding for OpenGL and is discussed in the author's > book: > > http://www.symbolstone.org/technology/java/nmbook/ > anybody intersting in implementing such a nice thing ? or should we just use the solution of a native awt component ? (allready discussed ..) cheers, sven - -- health & wealth mailto:sgo...@ja... www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ voice : +49-521-2399440 ; fax : +49-521-2399442 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8FZo5HdOA30NoFAARAt6+AJwO8xH0c2hG2pbqnE9qk+GZRIX1YgCgnOWS uLHkfHoJaNQQekpm6wNyvp8= =+JOF -----END PGP SIGNATURE----- |
|
From: Toshiyuki I. <is...@mi...> - 2001-12-11 10:02:10
|
Thanks for your reply. ----- Original Message ----- From: "Kenneth B. Russell" <kbr...@al...> Sent: Tuesday, December 11, 2001 2:09 PM > > > Also, I wish to speed up the GLJPanel with new API in JDK1.4 > > (e.g. the VolatileImage class and the java.nio package). > > GL4Java developers have any plan at this point? > > I think the way to get more speed out of GLJPanel is to avoid the > pixel copy that is occurring now, by keeping track of where the > GLJPanel is within the component hierarchy, clipping the OpenGL > rendering region appropriately, and drawing directly to the > heavyweight component to take advantage of hardware acceleration. > This won't work if the component is partially occluded, but that > rarely happens and the system could revert back to the current > pixel copy in that case. > I think so that copying pixel data slows down GLJPanel. I think that 'direct buffer' in JDK1.4 such as NVidia's support in gl4java may possibly improve this problem. However, I don't have knowledge about new io package. > I'm pretty sure this technique was used in the now-defunct > Magician Java binding for OpenGL and is discussed in the author's > book: > > http://www.symbolstone.org/technology/java/nmbook/ > I will visit this site. By using gl4java, we can built big and complex applications without depending on several GUI libraries. I think that this point is one of big advantages of gl4java. In fact, I am making a map application, which has many swing component. Maybe speeding up GLJPanel as Java lightweight component expand possibility of application development (e.g. MDI application with GL rendering). From these, I think that improvement of GLJPanel perfomance is important. So, I want to imporve it, but I have no idea. Regards, -- Toshiyuki Ishimura |
|
From: Sven G. <sgo...@ja...> - 2001-12-11 01:44:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 10 December 2001 21:30, NM...@th... wrote: > Hi, > > Regarding your first issue... > > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " . > the upside-down problem will be solved with this trick, without any big performance lost .. so, i might should add this to the class into the init method .. if nobody complains (please vote), i will do so ! i guess this is much faster, than the java image transformation ;-) thanxs to Noah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8FWT2HdOA30NoFAARAru7AJ0dMpEJLrBzLLVQlawSkFN9CVgI0QCdHwsI GIpsouRJZjv8RjIAmLqEwmU= =YFJg -----END PGP SIGNATURE----- |
|
From: Sven G. <sgo...@ja...> - 2001-12-11 02:24:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 11 December 2001 02:44, Sven Goethel wrote: > On Monday 10 December 2001 21:30, NM...@th... wrote: > > Hi, > > > > Regarding your first issue... > > > > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " . > > the upside-down problem will be solved with this trick, > without any big performance lost .. > > so, i might should add this to the class into the init method .. > > if nobody complains (please vote), i will do so ! > > i guess this is much faster, than the java image transformation ;-) > > thanxs to Noah > oops .. i guess i was to fast .. this is not a general purpose solution, a glRotatef neither .. a general purpose solution would be, like Toshiyuki's one, but i am afraid that this one is a big performance lost .. even if it works nice ! so, we must live with it, and the application should take care about it, or we better need a general purpose gl solution .. please send your ideas .. cheers, sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8FW5THdOA30NoFAARAqwXAJwO9HZi3czqXOElGV16BsGE5QAszACeLBuy fZgE8xdbKt1L2FaFdgVPZVQ= =V+kO -----END PGP SIGNATURE----- |
|
From: Toshiyuki I. <is...@mi...> - 2001-12-11 10:02:10
|
Thanks for your reply. ----- Original Message ----- From: "Sven Goethel" <sgo...@ja...> Sent: Tuesday, December 11, 2001 11:24 AM > On Tuesday 11 December 2001 02:44, Sven Goethel wrote: > > On Monday 10 December 2001 21:30, NM...@th... wrote: > > > Hi, > > > > > > Regarding your first issue... > > > > > > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " . > > > > the upside-down problem will be solved with this trick, > > without any big performance lost .. > > > > so, i might should add this to the class into the init method .. > > > > if nobody complains (please vote), i will do so ! > > > > i guess this is much faster, than the java image transformation ;-) > > > > thanxs to Noah > > > > oops .. i guess i was to fast .. > > this is not a general purpose solution, > a glRotatef neither .. > As my reply to Noah, I can't understand calling glTranslate. Please tell me its meaning. Here, I try to call 'gl.glScalef(1.0f, -1.0f, 1.0f)' after initialize MODELVIEW matrix. Then, the Panel shows the correct view without turning upside down. > a general purpose solution would be, like Toshiyuki's one, > but i am afraid that this one is a big performance lost .. > even if it works nice ! > > so, we must live with it, and the application should take care about it, > or we better need a general purpose gl solution .. > > please send your ideas .. > I think so. If any document about this problem (upside-down problem) is available, maybe I didn't comfuse. I wish to give some attension about this to users in FAQ, manual or API doc. Regards, -- Toshiyuki Ishimura |
|
From: Toshiyuki I. <is...@mi...> - 2001-12-11 10:02:11
|
Thanks for your reply. ----- Original Message ----- From: <NM...@th...> Sent: Tuesday, December 11, 2001 5:30 AM > Hi, > > Regarding your first issue... > > Try calling " gl.glTranslatef(0.0f,-1.0f,0.0f) " . > > For some reason the GLCanvas uses the left hand rule and the GLJPanel is > using the right hand rule. So when drawing scenes get kind of turned > around. I don't know whether this is documented anywhere, but I think it > should be added if it isn't. Or the "quirk" should maybe be looked at being > corrected so the two components are consistent. > I'm try to call 'gl.glTranslatef(0.0f,-1.0f,0.0f) ' in display() after initialize MODELVIEW matrix. However, my Panel still shows the reverse view. Sorry, I can't understand why calling glTranslate function. > As for your second issue, sorry, I am unable to help you out. > > Hope that helps, > Noah > -- Toshiyuki Ishimura |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X