cc: Sven_M
Miguel,
I'm trying to get Jmol running with open source virtual machines [1], and
while the application does not work yet, the renderer itself does, using the
Swing3D class...
Using the Awt3D, however, does not work. I've been talking to Sven_M on irc
(#classpath), and he thinks it has to do with the transparency the Gtk
backend uses. That is, Component.createImage() returns a
gnu.java.awt.peer.gtk.GtkImage, which uses RGBA instead of RGB, and thus
things get drawn transparent.
Added a line in Awt3D.java makes at least a black background again:
public void startProduction(ImageConsumer ic) {
if (this.ic != ic) {
this.ic = ic;
ic.setDimensions(windowWidth, windowHeight);
ic.setHints(ImageConsumer.TOPDOWNLEFTRIGHT |
ImageConsumer.COMPLETESCANLINES |
ImageConsumer.SINGLEPASS);
}
for(int i=0;i<pBuffer.length;i++) pBuffer[i] |= 0xFF000000; // RGBA thingy
ic.setPixels(0, 0, windowWidth, windowHeight, colorModelRGB,
pBuffer, 0, windowWidth);
ic.imageComplete(ImageConsumer.SINGLEFRAMEDONE);
}
But in the Integration.java the water is gone...
Sven_M also noted that we should use:
Awt3D(Component component) {
this.component = component;
// old code: colorModelRGB = ColorModel.getRGBdefault();
colorModelRGB = Toolkit.getDefaultToolkit().getColorModel();
}
But that did not improve it too.
It seems that the problem is the transparency. Miguel, do you have an idea why
the water does not get drawn?
Below is the full IRC log.
Egon
1.http://chem-bla-ics.blogspot.com/2005/11/open-source-swing-jmol-renderer-runs.html
[2005-11-27 21:29:38] <egonw_> mjw: I got the Jmol renderer working with jamvm
[2005-11-27 21:29:42] <theBohemia1> gcj-crew: ping
[2005-11-27 21:29:48] *** theBohemia1 is now known as theBohemian.
[2005-11-27 21:29:55] <egonw_> mjw: better -> it just works... (did not have
to do much)
[2005-11-27 21:30:00] <mjw> egonw_, Woot!
[2005-11-27 21:30:01] <egonw_> it's just very slow
[2005-11-27 21:30:04] <theBohemian> mjw: hi
[2005-11-27 21:30:05] <mjw> screenshot! screenshot!
[2005-11-27 21:30:13] <egonw_> mjw: mind... it's not the Jmol application...
[2005-11-27 21:30:16] <egonw_> just the renderer
[2005-11-27 21:30:22] <theBohemian> mjw: is there an ant task that does bc
compilation nicely?
[2005-11-27 21:30:37] <egonw_> mjw: will post a screenshot...
[2005-11-27 21:30:53] <mjw> egonw_, jamvm is not the faster engine around. Try
kaffe, cacao or natively compile it with gcj for a nice speed boost.
[2005-11-27 21:30:54] <egonw_> flickr.something... that's a place where one
can upload images, right?
[2005-11-27 21:30:58] <theBohemian> mjw: something more sophisticated than
calling exec
[2005-11-27 21:31:24] <mjw> theBohemian, I never use ant to be honest.
[2005-11-27 21:31:24] <egonw_> kaffe gives error:
[2005-11-27 21:31:30] <egonw_> java.lang.ClassCastException: can't cast
`java/awt/image/BufferedImage' to `gnu/java/awt/peer/gtk/GtkImage'
[2005-11-27 21:31:32] <theBohemian> mjw: :(
[2005-11-27 21:31:35] <mjw> theBohemian, But I believe green made something.
Let me look it up.
[2005-11-27 21:31:38] <egonw_> there a -D option for that right?
[2005-11-27 21:32:03] <mjw> egonw_, Maybe
-Dgnu.java.awt.peer.gtk.Graphics=Graphics2D
[2005-11-27 21:32:07] <theBohemian> mjw: thanks
[2005-11-27 21:32:11] <mjw> If you have compiled with cairo support.
[2005-11-27 21:32:26] <Sven_M> Yeah.
[2005-11-27 21:32:31] <theBohemian> egonw_: try a newer cp-snapshot for kaffe
[2005-11-27 21:32:33] <egonw_> mjw: no, that does not help...
[2005-11-27 21:32:45] <theBohemian> egonw_: mjw fixed this classcast thing a
few days ago
[2005-11-27 21:32:46] <mjw> Also you might need kaffe CVS since it got just
upgraded today with the latest GNU Classpath.
[2005-11-27 21:32:54] <egonw_> ack
[2005-11-27 21:33:07] <Sven_M> mjw: Where was the cast?
[2005-11-27 21:33:15] <mjw> http://spindazzle.org/gcjlib/
[2005-11-27 21:33:20] <mjw> Sven_M, cast?
[2005-11-27 21:33:27] <Sven_M> mjw: You fixed a GtkImage cast?
[2005-11-27 21:33:34] <mjw> Maybe
[2005-11-27 21:33:37] <mjw> I don't remember.
[2005-11-27 21:33:40] <Sven_M> That shouldn't happen.
[2005-11-27 21:33:42] <Sven_M> theBohemian: ?
[2005-11-27 21:33:43] <mjw> See the patches list if I did :)
[2005-11-27 21:33:54] <guilhem> egonw_: yes try the latest kaffe CVS.
[2005-11-27 21:34:02] <Sven_M> Last time I worked on GtkImage there were no
unchecked casts to GtkImage in the Classpath code.
[2005-11-27 21:34:10] <egonw_> guilhem: is there a kubuntu breezy deb for
that?
[2005-11-27 21:34:16] <mjw> theBohemian, http://spindazzle.org/gcjlib/ is what
you are looking for I believe.
[2005-11-27 21:34:31] <guilhem> egonw_: no. I don't think so.
[2005-11-27 21:34:59] <mjw> egonw_, Do you have a line number for that
ClassCastException?
[2005-11-27 21:35:02] <egonw_> guilhem: then I'll wait... (very busy with
finishing PhD... so no time for diving into compiling stuff)
[2005-11-27 21:35:07] <egonw_> mjw: yes
[2005-11-27 21:35:17] <egonw_> java.lang.ClassCastException: can't cast
`java/awt/image/BufferedImage' to `gnu/java/awt/peer/gtk/GtkImage'
[2005-11-27 21:35:17] <egonw_> at
gnu.java.awt.peer.gtk.GdkGraphics.drawImage (GdkGraphics.java:158)
[2005-11-27 21:35:46] <egonw_> at
gnu.java.awt.peer.gtk.GdkGraphics.drawImage (GdkGraphics.java:186)
[2005-11-27 21:35:46] <egonw_> at org.jmol.viewer.Viewer.render1
(Viewer.java:1597)
[2005-11-27 21:35:54] <egonw_> from then on it's Jmol code
[2005-11-27 21:36:35] <mjw> egonw_/Sven_M, then it looks like that is old
code.
[2005-11-27 21:36:39] <Sven_M> Those line numbers don't match. That must be a
very old version.
[2005-11-27 21:36:53] <mjw> The current drawImage code correctly checks before
casting.
[2005-11-27 21:36:59] <Sven_M> Before I rewrote GtkImage entirely. Unless
someone introduced one, there are no unchecked casts.
[2005-11-27 21:37:05] * egonw_ is not using CVS stuff
[2005-11-27 21:37:18] <egonw_> cp 0.18 I htink
[2005-11-27 21:37:18] <egonw_> mom
[2005-11-27 21:37:26] <egonw_> 0.18-5ubuntu1
[2005-11-27 21:37:34] <mjw> At least use 0.19 :)
[2005-11-27 21:37:47] <mjw> 0.18 is so 2 months ago!
[2005-11-27 21:38:47] <mjw> And while you are at it, try cacao with that.
[2005-11-27 21:38:54] <egonw_> mjw: no kubuntu deb :(
[2005-11-27 21:38:55] <mjw> Should work out of the box with 0.19!
[2005-11-27 21:39:14] <mjw> tsss tsss tsss. enduser! :)
[2005-11-27 21:39:19] <Sven_M> mjw: GtkImage was rewritten by then though, I
think.
[2005-11-27 21:39:35] <egonw_> mjw: :)
[2005-11-27 21:39:42] <mjw> Sven_M, Sure. But we don't know which kaffe
version he is using.
[2005-11-27 21:39:55] <egonw_> 1.1.5-5ubuntu2
[2005-11-27 21:39:55] <lindi-> egonw_: even debian has classpath 0.19 :)
[2005-11-27 21:39:57] <mjw> Sven_M, kaffe still comes with its own copy of
classpath...
[2005-11-27 21:40:02] <egonw_> sarge or sid?
[2005-11-27 21:40:08] <lindi-> egonw_: sid
[2005-11-27 21:40:18] <egonw_> mjw: I'm fairly OK with installing java stuff
from sid
[2005-11-27 21:40:21] <mjw> It was released like 2 weeks ago!
[2005-11-27 21:40:25] <dalibor> 1.1.5? tststs. bad ubuntu! ;)
[2005-11-27 21:40:38] <egonw_> ok, hang on...
[2005-11-27 21:40:39] <dalibor> 1.1.6 is already uh ... two months old, I
think.
[2005-11-27 21:40:40] <tashiro> egonw_: 0.19 was to late for breezy. dont know
for kubuntu
[2005-11-27 21:40:41] <Sven_M> mjw: Ok, but anyway this stuff was fixed back
in june already.
[2005-11-27 21:40:45] * egonw_ is updating Packages.gz for sid
[2005-11-27 21:40:45] <Sven_M> Early june at that.
[2005-11-27 21:41:24] <Sven_M> egonw_: Beware that the BufferedImage drawing
code with the non-cairo peers is slow as heck. :)
[2005-11-27 21:41:34] <egonw_> Sven_M: yes, I noted that :)
[2005-11-27 21:41:36] <mjw> Sven_M, Kaffe 1.1.5 is from April!
[2005-11-27 21:41:40] <Sven_M> Slow with the cairo peers too.. just not
super-slow :)
[2005-11-27 21:41:54] <egonw_> Sven_M: assuming jamvm was not using that...
actually...
[2005-11-27 21:41:58] <Sven_M> mjw: Yeah, yeah.. I suppose we should be happy
enough dalibor did a release at all ;)
[2005-11-27 21:42:07] <mjw> hehe
[2005-11-27 21:42:42] <Sven_M> egonw_: The whole GtkImage thing is just
provisional.
[2005-11-27 21:42:50] <dalibor> dude, a release evry 6 months is about 10
times faster than autoconf ;)
[2005-11-27 21:43:01] <egonw_> did I see correcly that work is ongoing on Qt
peers?
[2005-11-27 21:43:15] * dalibor guesses autoconf 2.59 came out in 2001, or so
[2005-11-27 21:43:22] <Sven_M> egonw_: Kind of.
[2005-11-27 21:43:32] <egonw_> as in Java/Qt bindings...
[2005-11-27 21:43:36] <Sven_M> egonw_: I wrote 'em. :) Haven't done much in
the last few months though.
[2005-11-27 21:43:38] <egonw_> or Qt peers for Swing stuff
[2005-11-27 21:43:40] <egonw_> ?
[2005-11-27 21:43:52] <guilhem> egonw_: Qt peers for awt.
[2005-11-27 21:43:53] <Sven_M> egonw_: Right, Qt peers for AWT (Swing)
[2005-11-27 21:44:18] <Sven_M> I wouldn't hype the Swing though, since it does
its own drawing and basically just uses AWT as a framebuffer.
[2005-11-27 21:44:59] <Sven_M> Which leads to the ironic result that if you've
got a nice Qt theme, AWT looks better than Swing. When it's usually
vice-versa.
[2005-11-27 21:45:13] * egonw_ is installing classpath 0.19 from debian sid
[2005-11-27 21:45:46] <egonw_> btw, I'm really happy with the Jmol renderer
running...
[2005-11-27 21:45:53] <mjw> egonw_, And if you are into installing random
weird shit then tashiro has some packages:
[2005-11-27 21:45:55] <mjw>
http://vern.chem.tu-berlin.de/~stephan/software/upload/
[2005-11-27 21:46:03] <egonw_> someone told me (or at least I thought so) that
BufferedImage was not working...
[2005-11-27 21:46:37] <dalibor> guilhem: oh, cool! nice proposal there on
deflating the target layer!
[2005-11-27 21:46:52] * mjw should look up the marketing term for "random
weird shit"...
[2005-11-27 21:47:11] <Sven_M> egonw_: BufferedImage is working in the sense
that you can draw them, slowly.
[2005-11-27 21:47:23] <Sven_M> egonw_: It's not working in the sense that you
can draw *to* them.
[2005-11-27 21:47:33] <egonw_> mmm...
[2005-11-27 21:47:47] * egonw_ needs to study the Jmol code again...
[2005-11-27 21:48:02] <egonw_> I thought Jmol was drawing bits in the
BufferedImage...
[2005-11-27 21:48:03] <Sven_M> So if you're using them for back-buffering,
well.. it ain't going to work, yet.
[2005-11-27 21:48:27] <Sven_M> egonw_: Drawing bits works, I guess. But
getting a Graphics object for it doesn't.
[2005-11-27 21:48:55] <egonw_> I have vague feeling that I'm starting to
understand...
[2005-11-27 21:49:44] <egonw_> that's fine...
[2005-11-27 21:49:50] <egonw_> Jmol is not using Java2D
[2005-11-27 21:51:24] <Sven_M> egonw_: 1.1-version AWT only?
[2005-11-27 21:51:34] <egonw_> yes
[2005-11-27 21:51:41] * mjw still demands a screenshot!
[2005-11-27 21:51:46] <egonw_> only way to get it working in many browsers...
[2005-11-27 21:51:47] <Sven_M> Where'd the BufferedImage come from?
[2005-11-27 21:51:51] <egonw_> mjw: yes, yes...
[2005-11-27 21:51:53] <egonw_> hang on...
[2005-11-27 21:51:55] <egonw_> working on it
[2005-11-27 21:52:18] <Sven_M> mjw: http://www.qc.physto.se/~sven/bevel.png
[2005-11-27 21:53:43] <mjw> Sven_M, Heay. Is that what I think it is?
[2005-11-27 21:54:52] <Sven_M> mjw: Backward 'l's!
[2005-11-27 21:54:58] <mjw> :)
[2005-11-27 21:55:32] <mjw> had hoped two it was 2 BasicStrokes munged
together.
[2005-11-27 21:56:59] <theBohemian> Sven_M: you're right. I was wrong
[2005-11-27 21:57:18] <theBohemian> Sven_M: mjw fixed the ClasscastException
in the GdkPixBufDecoder
[2005-11-27 21:57:54] <mjw> O right! I remember that one. That was for the
imageio streams.
[2005-11-27 21:58:17] <Sven_M> theBohemian: Good :) I distinctly remember
cleaning up all GtkImage casts back then, so I'd hate to have had a
regression there.
[2005-11-27 21:59:45] <guilhem> bye all !
[2005-11-27 21:59:49] <-- guilhem has left this server. ("Download Gaim:
http://gaim.sourceforge.net/";)
[2005-11-27 22:03:23] <theBohemian> mjw: I know the XMLEncoder code is a bad
shape
[2005-11-27 22:03:51] <theBohemian> mjw: but 'they' asked for it so dearly
[2005-11-27 22:04:14] <mjw> theBohemian, hehe. You cannot keep blaming "them"
for everything :)
[2005-11-27 22:04:23] <egonw_> mjw: your screenshot ->
http://chem-bla-ics.blogspot.com/2005/11/open-source-swing-jmol-renderer-runs.html
[2005-11-27 22:04:25] <mjw> theBohemian, There were certainly some good parts
in it.
[2005-11-27 22:05:14] <theBohemian> mjw: I found no time to continue the
implementation because of my job. Its like in this stallman text, I sell my
priority list ;)
[2005-11-27 22:05:19] <Sven_M> Cool. Water.
[2005-11-27 22:05:26] <theBohemian> mjw: ok, just kidding.
[2005-11-27 22:06:03] <theBohemian> mjw: anyway I asked about finishing the
encoder as part of my job and got an ok about this.
[2005-11-27 22:06:49] <mjw> Very nice screenshot.
[2005-11-27 22:07:08] <mjw> I see on the mailinglist we have another user
complaining about slowness.
[2005-11-27 22:07:10] <mjw> hmmmm
[2005-11-27 22:07:20] <mjw> theBohemian, Wow! That is so nice!
[2005-11-27 22:07:40] <mjw> theBohemian, And please do feel free to commit
those parts you are happy about.
[2005-11-27 22:08:05] <mjw> theBohemian, And even the bad parts if you can add
some documentation on how you would like to see it improved/redesigned.
[2005-11-27 22:08:32] <egonw_> mjw: I would have love to demo a protein...
[2005-11-27 22:08:37] <egonw_> actually...
[2005-11-27 22:08:45] <egonw_> that might not be that much slower...
[2005-11-27 22:08:54] <egonw_> it's rendering the BufferedImage that is slow,
correct?
[2005-11-27 22:09:28] <Sven_M> egonw_: Shouldn't be any BufferedImage involved
though unless you're using Graphics2D.
[2005-11-27 22:09:40] <egonw_> Sven_M: hang on...
[2005-11-27 22:10:01] <mjw> I would say, compile to native and use oprofile on
it! :)
[2005-11-27 22:10:04] <Sven_M> Otherwise it should use GtkImage and then it
draws to an X pixmap. Which means blitting it is about as fast as it can get.
[2005-11-27 22:10:29] <Sven_M> Or rather, GtkImage = X Pixmap
[2005-11-27 22:10:39] <theBohemian> mjw: yep. I separate the doc fixes and
such tommorow and send them in.
[2005-11-27 22:10:52] * theBohemian not feeling well today and need some
sleep.
[2005-11-27 22:10:57] <theBohemian> cya
[2005-11-27 22:11:03] <egonw_> Sven_M: could you have a look at these bits of
code:
[2005-11-27 22:11:04] <-- theBohemian has left this channel. ()
[2005-11-27 22:11:28] <egonw_> ...
[2005-11-27 22:11:39] <egonw_>
http://cvs.sourceforge.net/viewcvs.py/jmol/Jmol/src/org/jmol/g3d
[2005-11-27 22:11:51] <egonw_> -> Swing3D.java and AWT3D.java
[2005-11-27 22:12:44] <egonw_> If I understand you correctly, I need to ensure
that Jmol uses the AWT3D and not they Swing3D...
[2005-11-27 22:12:46] <egonw_> correct?
[2005-11-27 22:13:23] <egonw_> Jmol picks one of the two depending on the
platform...
[2005-11-27 22:14:40] <egonw_> which is done in the Platform3D.java in the
same dir...
[2005-11-27 22:15:07] * egonw_ is attempting to force AWT, and see what
happens...
[2005-11-27 22:15:34] * egonw_ is recompiling...
[2005-11-27 22:15:53] --> grey_gandalf has joined this channel.
([EMAIL PROTECTED])
[2005-11-27 22:15:59] <grey_gandalf> mjw: hey
[2005-11-27 22:16:01] <grey_gandalf> hey all§
[2005-11-27 22:17:23] <grey_gandalf> mjw: when I start my applications one of
the panel is drawn wrongly
[2005-11-27 22:17:28] <grey_gandalf> but no exceptions
[2005-11-27 22:17:59] <grey_gandalf> (wrongly: 1. wrong size, 2. it has no
hide arrows)
[2005-11-27 22:19:46] <mjw> grey_gandalf, Hi Riccardo
[2005-11-27 22:20:08] <egonw_> Sven_M: forcing the AWT version breaks it :(
[2005-11-27 22:20:09] <Sven_M> egonw_: The Swing3D thing uses BufferedImage I
see, so yeah, that won't work as well.
[2005-11-27 22:20:30] <egonw_> Sven_M: but you've seen the screenshot ?!?!
[2005-11-27 22:20:31] <grey_gandalf> hey sven !
[2005-11-27 22:20:39] <Sven_M> 'lo grey_gandalf
[2005-11-27 22:20:42] <grey_gandalf> mjw when I click to open an inspector
panel I get
[2005-11-27 22:20:43] <grey_gandalf>
http://rafb.net/paste/results/Rbv6y257.html
[2005-11-27 22:21:16] <grey_gandalf> if I try to resizze the pane, the drag
line gets drawn in black, I start dragging but when I relese.. nothing
happens, the black line remains
[2005-11-27 22:21:16] <mjw> grey_gandalf, This is with kaffe CVS right?
[2005-11-27 22:21:34] <grey_gandalf> mjw: yes, fresh fresh... thus I tihnk
quite up-tpo-date CP
[2005-11-27 22:21:44] <grey_gandalf> guilhem synced this afternoon
[2005-11-27 22:22:03] <grey_gandalf> mjw: if you want to try the application
on gcj or something like that...
[2005-11-27 22:22:22] <egonw_> Sven_M: the swing one works, the AWT does
not...
[2005-11-27 22:22:41] <Sven_M> egonw_: Wacky.
[2005-11-27 22:23:00] <Sven_M> egonw_: Ok, are you using Graphics2D/Cairo or
not?
[2005-11-27 22:23:08] <egonw_> jamvm 1.3.3
[2005-11-27 22:23:12] <Sven_M> egonw_: And what isn't working about the AWT
version?
[2005-11-27 22:23:26] <egonw_> I get a grey content instead of the black +
water
[2005-11-27 22:23:29] <mjw> grey_gandalf, Looking at the source of
ScrollPaneLayout and Container. Let me think.
[2005-11-27 22:23:31] <Sven_M> egonw_: Well, ok, but which classpath and did
you build it with Graphics2D support?
[2005-11-27 22:23:42] <egonw_> debian sid packages
[2005-11-27 22:23:46] <egonw_> classpath 0.19
[2005-11-27 22:23:48] <egonw_> -2
[2005-11-27 22:24:46] <Sven_M> egonw_: Ok, hmm.. uh, could you tell me what
Component.createImage(int, int) returns?
[2005-11-27 22:25:02] <egonw_> class type?
[2005-11-27 22:26:13] <egonw_> hang on
[2005-11-27 22:28:19] <egonw_> Sven_M: gnu.java.awt.peer.gtk.GtkImage
[2005-11-27 22:29:53] <Sven_M> egonw_: Ok. That's good. Hmm. You know what it
*could* be? Could be that you're assuming that the native pixel format is
32-bit RGB, when it tends to default to 32-bit RGBA with GtkImage (IIRC),
meaning you've got a zero alpha channel --> the thing is being drawn
transparently!
[2005-11-27 22:30:01] <mjw> grey_gandalf, Interesting. Still looking what this
should actually do.
[2005-11-27 22:30:07] <grey_gandalf> :)
[2005-11-27 22:30:09] <mjw> grey_gandalf, Well done. You found a bug! :)
[2005-11-27 22:30:19] <egonw_> Sven_M: OK, how to test that?
[2005-11-27 22:30:37] <grey_gandalf> mjw: that is why people fear me :)
[2005-11-27 22:30:39] <egonw_> Sven_M: or fix that...
[2005-11-27 22:32:11] <Sven_M> egonw_: Good question. Hmm... Easy. Dump the
first few ints in pBuffer there.
[2005-11-27 22:32:47] <Sven_M> egonw_: Should be 0xFF000000 (or 0x000000FF)
for black and not 0.
[2005-11-27 22:33:01] <egonw_> ok, where do I do that?
[2005-11-27 22:33:10] * egonw_ is looking... mom
[2005-11-27 22:33:25] <Sven_M> egonw_: Well, at some spot when you know the
image is drawn.. :)
[2005-11-27 22:33:36] <grey_gandalf> mjw: were you able to find a fix too? :)
[2005-11-27 22:34:05] <mjw> grey_gandalf, I am not sure.
[2005-11-27 22:34:13] <egonw_> ok, I see something promosing:
ic.setPixels( bla bla, pBuffer, bla bla)
[2005-11-27 22:34:29] <mjw> grey_gandalf, So you add this thing to the
ScrollPaneLayout.
[2005-11-27 22:34:33] <Sven_M> egonw_: Yeah, maybe in that startProduction
method.
[2005-11-27 22:34:51] <mjw> grey_gandalf, I assume you expect it to show up in
the main viewport.
[2005-11-27 22:34:54] <Sven_M> it should be called every time the image is
recreated/redrawn
[2005-11-27 22:35:32] <egonw_> 4 bytes enough?
[2005-11-27 22:36:07] <grey_gandalf> mjw: let me check the line
[2005-11-27 22:36:15] <grey_gandalf> I add many scoll things :)
[2005-11-27 22:36:30] <egonw_> Sven_M: all first four is zero...
[2005-11-27 22:36:31] <Sven_M> egonw_: If the top-left corner is black, then
yes :)
[2005-11-27 22:36:35] <egonw_> that's what you expected right?
[2005-11-27 22:36:51] <Sven_M> egonw_: Well, it'd fit with theory above.
[2005-11-27 22:36:52] <egonw_> that's ... that means transparent, correct?
[2005-11-27 22:37:01] <Sven_M> egonw_: Right.
[2005-11-27 22:37:08] <egonw_> OK, will relay this to the rendering engine
developer...
[2005-11-27 22:37:08] <Sven_M> I think.
[2005-11-27 22:37:25] <egonw_> OK, and using AWT would be faster, correct too?
[2005-11-27 22:37:26] <Sven_M> Yup, we default to RGBA.
[2005-11-27 22:37:38] <-- rabbit_ has left this server. (Connection timed out)
[2005-11-27 22:37:46] <grey_gandalf> mjw: intrestingly, it is some code that
currently doesn't work very well
[2005-11-27 22:37:54] <Sven_M> I'm pretty sure the JDK doesn't though.
[2005-11-27 22:38:09] <Sven_M> Or is it the other way around..
[2005-11-27 22:39:03] <Sven_M> egonw_: Hmm.. try a workaround.
[2005-11-27 22:40:25] <egonw_> suggestions?
[2005-11-27 22:40:35] <Sven_M> egonw_: Add to the startProduction() method
something a la for(int i=0;i<pBuffer.length;i++)pBuffer[i] |= 0xFF000000;
[2005-11-27 22:40:48] <Sven_M> So you set the alpha channel to opaque.
[2005-11-27 22:41:00] <egonw_> Sven_M: ack, hang on
[2005-11-27 22:44:04] <egonw_> Sven_M: OK, I now have a black background
[2005-11-27 22:44:57] <egonw_> but the water is gone
[2005-11-27 22:45:43] <Sven_M> Huh.
[2005-11-27 22:46:05] <Sven_M> egonw_: Well that's pretty weird! :)
[2005-11-27 22:47:38] <egonw_> but not something Miguel will not understand...
[2005-11-27 22:47:46] <egonw_> do you want to be cc-ed?
[2005-11-27 22:48:16] <Sven_M> Hmm.. this might be your problem, actually:
colorModelRGB = ColorModel.getRGBdefault();
[2005-11-27 22:48:22] <Sven_M> Or maybe it's our problem.
[2005-11-27 22:48:29] <Sven_M> But I think it's yours.
[2005-11-27 22:48:33] <egonw_> :)
[2005-11-27 22:48:47] <Sven_M> ColorModel.getRGBdefault() is 32-bit RGB.
[2005-11-27 22:48:55] <egonw_> OK, I'll email Miguel... he's far more
knowlegdable in these matters than I am...
[2005-11-27 22:49:04] <egonw_> Sven_M: makes sense...
[2005-11-27 22:49:10] <egonw_> is there a RGBA default too?
[2005-11-27 22:49:11] <Sven_M> But it's NOT necessarily the default colorModel
used by Component.createImage()
[2005-11-27 22:49:43] <egonw_> do you have a suggestion?
[2005-11-27 22:49:43] <Sven_M> Which is returned by Toolkit.getColorModel().
[2005-11-27 22:49:53] <egonw_> OK
[2005-11-27 22:49:56] <egonw_> mom, will try
[2005-11-27 22:50:14] <Sven_M> egonw_: Yeah, so try changing that to
Toolkit.getDefaultToolkit().getColorModel().
[2005-11-27 22:50:23] <Sven_M> I'm assuming you *use* this later :)
[2005-11-27 22:50:29] <egonw_> :)
[2005-11-27 22:51:08] <Sven_M> Could be that you're drawing a transparent
water onto a nontransparent black background or something.
[2005-11-27 22:51:36] <egonw_> yeah...
[2005-11-27 22:51:43] <egonw_> recompiling...
[2005-11-27 22:52:20] <egonw_> does not do anything...
[2005-11-27 22:52:39] <egonw_> it is used though...
[2005-11-27 22:52:44] <egonw_> in the setPixels call...
[2005-11-27 22:56:12] <Sven_M> egonw_: Oh right.
[2005-11-27 22:57:21] <-- man-di2 has left this server. ("Verlassend")
[2005-11-27 22:57:25] <Sven_M> That shouldn't matter though, I mean if we're
setting the alpha channel to 255.
[2005-11-27 22:57:36] <egonw_> indeed...
[2005-11-27 22:57:51] <egonw_> I'm pretty sure Miguel will understand what is
going on...
[2005-11-27 22:58:05] <egonw_> Sven_M: if you message me your email address,
I'll cc you
[2005-11-27 22:58:13] <Sven_M> egonw_: [EMAIL PROTECTED]
[2005-11-27 22:59:27] <Sven_M> egonw_: BTW, does Jmol handle Molden frequency
files?
[2005-11-27 22:59:43] <egonw_> send a file and then we can add it
[2005-11-27 23:00:04] <egonw_> (assuming that they store the frequencies as
vectors)
--
[EMAIL PROTECTED]
Blog: http://chem-bla-ics.blogspot.com/
GPG: 1024D/D6336BA6
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
