Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?
Last time I looked, both C and C++ had runtime code -- I suppose one could dispute that that code created a runtime environment. I wouldn't argue with that. And if the design of an API is so complex that the average programmer can't understand how to use it is the hallmark of good design -- well then you win -- BufferedImage great design. jav...@javadesktop.org wrote: The first thing that you will have to understand is that Java is going to be slower than anything except maybe Flash. If your goal s to be as fast as C, C++, C# or .Net then you should find another goal because it is already a given that Java will be slower. You mix up runtime enviroments and languages. However nice try. But your experiments are important because they will reveal the flaws and inconsistencies in Java2D, BufferedImage and ImageIO. Just because their design is too flexible for you to understand, doesn't mean its flawed. - Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=349645 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help.
Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?
The first thing that you will have to understand is that Java is going to be slower than anything except maybe Flash. If your goal is to be as fast as C, C++, C# or .Net then you should find another goal because it is already a given that Java will be slower. Another way to display an image is the use of MemoryImageSource and BufferStrategy which can be very useful for animations but not necessarily faster in loading since the only way to load a tif image is with ImageIO and BufferedImage. But your experiments are important because they will reveal the flaws and inconsistencies in Java2D, BufferedImage and ImageIO. Note them down carefully. A complete study of all the various pathways an image can take from disk to display along with timings for each pathway would be an even more valuable task than the task you are currently attempting. Making a catalog of all the ways Java can make an image and the pitfalls and workarounds necessary for many of those paths would make a very valuable white paper. It will not be an easy task. If you work on a task like that, don't forget to look carefully at ImageReadParam and how that can be used and how it can lead to a multitude of dead ends. It is no small task to do this but you will learn a lot and that knowledge will be valuable. jav...@javadesktop.org wrote: Thank you Dmitri for your answer. Excuse me if some of the above comments are incorrect, but i am new to Java2D programming. Also, i would GREATLY appreciate if there is yet another method to do what i want (e.g. load and display an image) in a faster way. To be honest i am creating an app here and i compare it with the speed of others that are written in native code (or even .NET) and mine is much slower. It's hard to accept that i cannot do with Java what others are doing with c or .net, === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help.
Re: [JAVA2D] Java2d Hardware Scaling Visual Artifact Problem w/Bilinear Interpolatio
And by the way -- BufferedImages still suck big time. jav...@javadesktop.org wrote: [quote]So I will attempt to hereby gracefully disengage...[/quote] Yes, and I suggest to go further and not re-engage. Dmitri [Message sent by forum member 'trembovetski' (trembovetski)] http://forums.java.net/jive/thread.jspa?messageID=329304 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help.
Re: [JAVA2D] Java2d Hardware Scaling Visual Artifact Problem w/Bilinear Interpolatio
Yes, if you deconstruct the notion of making an API complete into it doesn't work vs. it's not there to begin with. No, I'm not referring to MIS vs. BufferedImage -- directly. And I'm not really in the mood for another argument which this discussion will degenerate to in about 2 emails. So I will attempt to hereby gracefully disengage... jav...@javadesktop.org wrote: Really? -- happy? -- How come SUN guys give me so much crap when I ask for an enhancement to First of all there's difference between a bug and a request for enhacement. speed up what I want to do? Without knowing what you are talking about, I guess, most likely they consider that stuff as unimportant. I hope you are not still referring to MIS vs. BufferedImage ;) - Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=329148 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help.
Re: [JAVA2D] Java2d Hardware Scaling Visual Artifact Problem w/Bilinear Interpolatio
Really? -- happy? -- How come SUN guys give me so much crap when I ask for an enhancement to speed up what I want to do? jav...@javadesktop.org wrote: The best workaround is to write your own bi-linear interpolator. Best Workarround? This means loosing hw-accaleration :-/ They are the easiest interpolator to write and then you won't have to argue with the SUN guys... Well, I am sure the SUN guys are happy about every report they get. - Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=328684 === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help. === To unsubscribe, send email to lists...@java.sun.com and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to lists...@java.sun.com and include in the body of the message help.
Re: [JAVA2D] Drawing to an off screen buffer
Do you get reasonable animation with this method? How many frames a second do you get using invokeLater()? [EMAIL PROTECTED] wrote: You don't need a BufferStrategy or VolatileImage unless you are doing live animation. It was hard to tell from your message if that was the case. I usually use a BufferedImage that you get from createCompatibleImage and draw using Java2D to the graphics context you get from it. When the plot is ready hand it over to the event dispatch thread and tell some component to paint it with invokeLater(). Otherwise look for examples that use BufferStrategy... [Message sent by forum member 'swpalmer' (swpalmer)] http://forums.java.net/jive/thread.jspa?messageID=301594 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Optimizing concentric arcs
YES! Why not FPU acceleration? That's what it's there for. Er... is StrictMath already FPU accelerated? If it is then, oh well... The current Math package is really not very good. Especially for low level graphics stuff where 5 significant digits is the minimum accuracy that is useful. [EMAIL PROTECTED] wrote: I've wanted to gripe about the slowness and inaccuracy of the Math package but who do I talk to? I totally agree. It would be great if the programmer could choose between the StrictMath implementation which is hard-wired now and maybe something like, call ist FastMath. FastMath could be implemented without any guarantees, and really 1:1 instrified in hotspot to a corresponding CPU instruction if there is any, that would be really cool :) lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=301657 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Dynamics of acceleration of BufferedImages (managed images)
Dmitri Trembovetski wrote: That's the idea. The developer shouldn't be worrying about this stuff, it should work for most cases. For those cases where the user needs tweaking or resource management there are APIs like setAcceleratedPriority and the like. -- That's exactly the kind of stuff what a real programmer should be worrying about. And what if someone (like me or the author of this thread) run into a case where it doesn't quite work the way we want it to? We're screwed because we can't get to the foundation classes to fix the problem. Give us the primitives and let us figure out how to use them. You (the Java Dev Team) are trying to do too good a job. The first accessible layer should be the primitives (well documented) and then you can layer higher level API's on top for accessabliity and ease of use for less accomplished programmers. High level API's as you've implemented in Java2D are really useful and make the job a whole lot easier. But there are times when you really need the low level stuff at your finger tips so you *CAN* change stuff. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Dynamics of acceleration of BufferedImages (managed images)
In most cases, the principles you've outlined are completely valid. But there are programming problems that are best solved by a *STUDIED USE* of the foundation primitives. Yes, a less experienced programmer can really muck things up by random changes in the foundation API's. I've seen it happen. In fact even Java releases cycle through that problem. But those kinds of problems are self curing. You can't sell software that won't run. There is a real psychological bias in development teams (not just the Java team) that thinks nobody else is technically capable. Common human nature -- our tribe is the only tribe etc. But in fact, there are a lot of really good programmers in the World who can cope with and even improve Java even at the lowest levels. I'm not advocating Open Source -- or as I like to refer to it Open Sores programming. That's one can'o'worms I don't want to get tangled up in. But no team -- no matter how technically skilled they are -- can anticipate *EVERY* need and encapsulate a universal solution. Just can't happen. Give us the primitives and layer the higher levels of abstraction on top and let us decide how to use them. One characteristic of maturity is the willingness to allow others responsibility for their own actions. Let us grow with you... Nidel, Mike wrote: I don't strictly disagree, but one of the reasons for abstraction like this is to enable your own development team to change the implementation without having to change the API. I may be wrong, but my sense is that this has been a motivating factor for the Java2D team. Once you allow developers to peek under the hood, then they start optimizing their code using the low-level components and bypassing the abstractions you've created. Then when you make changes to the underlying objects and their interactions, it breaks everyone's applications because they relied on those interactions. To make a gross generalization, to me this is the difference between thinking like a C/C++ developer versus a Java developer. Java builds in so many abstractions, from garbage collection to Swing to stuff like managed images. In my opinion, C++ development generally exposes more of the underlying workings of the components. That's not to say one or the other is objectively better, obviously every tool has its use, but I'm giving a reason why a system developer might not want to expose the inner implementation of their system. That's just my take when trying to see it from the other side. Mike -Original Message- From: Discussion list for Java 2D API [mailto:[EMAIL PROTECTED] On Behalf Of Ken Warner Sent: Thursday, September 11, 2008 12:54 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA2D] Dynamics of acceleration of BufferedImages (managed images) Dmitri Trembovetski wrote: That's the idea. The developer shouldn't be worrying about this stuff, it should work for most cases. For those cases where the user needs tweaking or resource management there are APIs like setAcceleratedPriority and the like. -- That's exactly the kind of stuff what a real programmer should be worrying about. And what if someone (like me or the author of this thread) run into a case where it doesn't quite work the way we want it to? We're screwed because we can't get to the foundation classes to fix the problem. Give us the primitives and let us figure out how to use them. You (the Java Dev Team) are trying to do too good a job. The first accessible layer should be the primitives (well documented) and then you can layer higher level API's on top for accessabliity and ease of use for less accomplished programmers. High level API's as you've implemented in Java2D are really useful and make the job a whole lot easier. But there are times when you really need the low level stuff at your finger tips so you *CAN* change stuff. == = To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. mailgw3.lmco.com with ESMTP id m8BH4ZcP017142; Thu, 11 Sep 2008 13:04:35 -0400 (EDT) Received: from swjscmail2.sun.com (swjscmail2.Sun.COM [192.18.99.108]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8BGtCvR019976; Thu, 11 Sep 2008 16:55:29 GMT Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.sun.com (8.11.7p3+Sun/8.11.7) with ESMTP id m8BGsFj05970; Thu, 11 Sep 2008 10:54:15 -0600 (MDT) Received: by JAVA.SUN.COM (LISTSERV-TCP/IP release 15.0) with spool id 2358172 for [EMAIL PROTECTED]; Thu, 11 Sep 2008 10:54:32 -0600 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by swjscmail1.java.sun.com (Postfix) with ESMTP id AEE023A82E for [EMAIL PROTECTED]; Thu, 11 Sep 2008 10:54:31 -0600
Re: [JAVA2D] Dynamics of acceleration of BufferedImages (managed images)
I have just a simple, non-threatining, non-hostile question: BufferedImage seems to be the crossroads for almost every operation in Java2D. If you are reading an image using ImageIO then BufferedImages are the object created. Drawing the image to the screen seems to be focused on drawing a BufferedImage. I'm skipping details here but overall, BufferedImage seems to be central to all Java2D ops. Why not give a little separation between BufferedImages and general image/imagefile manipulations? Keep BufferedImage as an important option to display an image and be more flexible in other operations like reading/writing/modifying an image. I'm not looking for a fight. Dmitri Trembovetski wrote: [EMAIL PROTECTED] wrote: Three questions: 1) After a image.flush(), is it possible to somehow indicate to the BufferedImage (managed image) that I want it to again allocate backing vram? (Without it having to be drawn twice or whatever - that would be too slow, as I might only be drawing the image a few times). Currently there isn't. You can 'pre-warm' the image by copying it twice to an accelerated destination (a VI or BS) - no need to copy whole image, just 1 pixel is enough, use drawImage variant which specifies src and dest rectangles. I was thinking about adding this ability to affect when the image is cached through the acceleration priority property. Say if you set it to 1.0 then we cache it on the first copy instead of the second. We already use acceleration priority for disabling caching of the image (if you set AP to 0.0). 2) When using ImageIO, sticking a BufferedImage into the params object (forcing the ImageIO to use the supplied BI instead of allocating itself), will this permanently defeat acceleration for this BI instance? (Basically, does ImageIO access the data buffer? If it does, is there some magic there that could internally tell the system to re-copy the data buffer to VRAM?) You can certainly test it yourself, but it should work fine with built-in plugins, at least in the latest jdks. 3) How can I know whether I have acceleration of the complete drawing sequence or not? .. whether the BIs in question currently have backing VRAM, and that my full-screen drawing is running at absolute fullest speed possible? Is about 40-50 frames per second on a 1280x1024 display on a 3GHz P4 with an ATI card accelerated or not? Basically, is the fact whether you have backing VRAM very obvious (like 1 fps to 1000 fps), or more subtle? There's no way to tell if you rendering operation will be hw accelerated if that's what you're asking. You can find if an image is currently cached by using Image.getCapabilities(). Background: I have this cache of BufferedImages. For a image organization application I have, I found that the GC had to work way to hard when I allocated large 4-10 MPix images in what ends up as a thight loop when the users scrolls along as fast as possible. This gave rise to extreme GC activity, since no such image (e.g. 7Mx4bytes) is small enough to end up in eden/survivors, thus all the time ending up in tenured/old space. This results in that the GC have to do full sweeps to free, apparently employing stop-the-world tactics (when scrolling fast through images, the app paused for seconds very frequently). So what I did, was to make a cache of BufferedImages which I allocate from. This instantly reduced the GC activity to near zero (since pretty much all BI allocations are removed except for the intial round), and works like a charm. What I have ended up wondering about, though, is how this affects acceleration. I invoke bi.flush() upon re-entry into the cache, since it might be a while before that specific size image is needed again. What I'd want, is to state bi.accelerate() before giving it out of the cache. Is this possible? After the ImageIO reading, I'd love if I could state to the BI that The data has changed, re-copy the current data to backing vram/volatile image/whatever (Or at least that the ImageIO itself did this magically, since everything else of the BI stuff is magical). Like I mentioned, we may be able to use setAccelerationPriority for that. My thought: It would be good if the managed image aspect became a bit more explicit: In addition to flush(), which obviously is exactly such an explicit method denoting I won't be using this BI for drawing for a while (or ever again), please ditch the backing VRAM, also an I'm going to begin using this image again, please allocate backing VRAM, and finally a The data of this image has changed - re-copy to backing VRAM, please method. Maybe also a is this BI still managed, or have I done something that defeats it?, in which case I could invoke the former method. Or maybe just combine the two latter into if I've done something to defeat acceleration, then now re-copy the data into the backing VRAM. Understood. Some of this you
Re: [JAVA2D] Copying a portion of an Image?
I'd suggest starting with a BufferedImage rather than an Image. They don't play well together... [EMAIL PROTECTED] wrote: I feel fairly stupid asking this question, as it seems like an operation that should be pretty simple, and it probably is, but for whatever reason I can't figure out the best way to do it. So I'm sorry in advance. :-) I'd like to create a new BufferedImage from the contents of a subregion of an existing java.awt.Image. What is the best, least bloated, least convoluted way to do this? Thanks in advance, Laird [Message sent by forum member 'ljnelson' (ljnelson)] http://forums.java.net/jive/thread.jspa?messageID=295189 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage.validate() does not (always) work
If you call repaint() you invoke the AWT thread and paint() is called by the AWT thread. update() and paint() should not be called directly by your program they are generally called from the AWT thread in response to some sort of system event like Expose or Move etc. With VolitileImages, you should render directly from your program by calling your own render method directly. Don't call repaint(). Dmitri, did I get that right? [EMAIL PROTECTED] wrote: Hi Ken, I'm just at work and see that I call it indirectly through repaint(). To be honest, it confuses me a bit that there are the methods repaint(), paint(Grphics g) and even update(Graphics g). I'm sure that I read about the differences and when I have to use one or the other at the time I was first creating my panel, but now, I just don't know anymore the differences and meanings of them . . . . Maik [Message sent by forum member 'kiamur' (kiamur)] http://forums.java.net/jive/thread.jspa?messageID=291504 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage.validate() does not (always) work
That's the way I do things. I do active rendering using BufferStrategy. I turn off repaint() setIgnoreRepaint(true) while I'm active rendering and then when I'm not active rendering and the applet is just sitting there, I turn on repaint() with setIgnoreRepaint(false) so that if the applet gets covered and then re-exposed, it repaints on the screen properly. My paint() method looks a lot like my active rendering method with slight differences in the implementation. I think that way of drawing on the screen is great especially if you need a high frame rate. Depending on the size of the screen area rendered to, I can get a frame in less than 100 milliseconds on my old, slow computer. The tricky part is trying to get the look and feel of the applet to be constant on computers with much faster graphics and processors. I try to adjust the amount of drawing by calculating the average number of frames per second and then adjusting the movement of the image. Lot's of fussy details... Dmitri Trembovetski wrote: You can certainly use repaint() with VolatileImages as back buffers. The alternative approach is called active rendering, where you control when stuff gets rendered. Take a look at this: http://java.sun.com/docs/books/tutorial/extra/fullscreen/rendering.html While this is a full screen tutorial, the same applies for rendering in windowed mode. Also, I reiterate, it is better to use active rendering and BufferStrategy for double buffering, especially if your application is 'game-like'. Thanks, Dmitri [EMAIL PROTECTED] wrote: Hi Ken, With VolitileImages, you should render directly from your program by calling your own render method directly. Don't call repaint(). I do use my own render method, but that method only renders on my background volatile image. After that is finished I somehow have to get my image onto the screen (or to be more precise on my panel). Then, I assume, I have to call repaint() (of the panel) out of my own render method, don't I? Maik [Message sent by forum member 'kiamur' (kiamur)] http://forums.java.net/jive/thread.jspa?messageID=291577 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] VolatileImage.validate() does not (always) work
Do you call paint method directly or indirectly through repaint()? [EMAIL PROTECTED] wrote: Does your rendering loop run on the event dispatch thread or some other thread? Well, I am not that familiar with the event dispatch thread and myabe that's the problem in my code . . . . To render my image, which should happen at a fixed rate of 20Hz, I use a Timer which calls my render method in its scheduleAtFixedRate() method. In my render method, I check for the graphicsConfiguration and call the validate() method of my vlatile image. After that, i draw my stuff on the Graphics2D object of the image. Finally, i call the paint()-method (I think it is so, will check that tomorrow at work) of the panel in which the image is situated and let the image be displayed. I don't know, if all that happens in the event dispatch thread, but I assume it should be, right . . . . ? [Message sent by forum member 'kiamur' (kiamur)] http://forums.java.net/jive/thread.jspa?messageID=291427 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] BufferStrategy problem with resize events
Are you overriding update() and paint() and do you
setIgnoreRepaint(true) on your component?
[EMAIL PROTECTED] wrote:
I am using BufferStrategy with 2 buffers to render off screen and then blast
the contents on to the screen and I am impressed with the simplicity of it and
its performance. However, there is a VERY serious problem with it, at least
the way I am using it. It seems that whenever the JFrame is resized something
is causing the screen to be cleared. The result is bad flickering or, even
worse, a totally blank screen.
I am using BufferStrategy in the technique in the JavaDoc as follows:
[code]
do {
do {
g2d = (Graphics2D)this.strategy.getDrawGraphics();
// Perform rendering here...
g2d.dispose();
} while (this.strategy.contentsRestored());
strategy.show();
} while (strategy.contentsLost());
[/code]
The clearing of the screen happens after any calls to strategy.show() and even
if I call it repeatedly after a resize event it seems that the screen will
clear after the last call. All that is required to restore the screen's
contents is to render again but I cannot work out how to trap this screen
clearing event and therefore know when to re-render.
Why is the screen clearing after the frame is resized? Is there a way to
prevent this, perhaps by using a different actual strategy for the
BufferStrategy? The screen clearing after resizing doesn't occur if I just
manually use a BufferedImage instead.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] BufferStrategy problem with resize events
I would revert to the use of the Java Docs recommended do/while loops.
They work well. And you will have to figure out when to call your
rendering method.
I use MemoryImageSource and render with the do/while loops
in my newPixels() method. I use paint() with the do/while
loops for expose events. And I toggle setIgnoreRepaint()
as needed.
The mods to you've made to the do/while loops look unnecessary.
But our apps are different.
You are on the right track. Don't forget about overriding update().
[EMAIL PROTECTED] wrote:
OK I have it working by overriding paint() to call the rendering method but
this seems like a bit of wasted effort, at least on some occasions. Anyway,
it's working but I have noticed that almost every render has to happen twice
because the strategy.contentsRestored() method returns true.
Is this normal? The following is a cut-down version of the code which exhibits
this problem.
[code]
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.event.ComponentAdapter;
import java.awt.event.ComponentEvent;
import java.awt.image.BufferStrategy;
import javax.swing.JFrame;
import javax.swing.JPanel;
public class StrategyTest extends JFrame {
private class MyPanel extends JPanel {
public MyPanel() {
this.setIgnoreRepaint(true);
this.addComponentListener(new ComponentAdapter() {
@Override
public void componentResized(final
ComponentEvent e) {
StrategyTest.this.render();
}
});
}
}
private final BufferStrategy strategy;
private Graphics2D g2d;
public StrategyTest() {
this.setLayout(new BorderLayout());
this.add(new MyPanel(), BorderLayout.CENTER);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
this.pack();
this.setSize(1024, 768);
this.setIgnoreRepaint(true);
this.createBufferStrategy(2);
this.strategy = this.getBufferStrategy();
}
public static void main(final String[] args) {
new StrategyTest().setVisible(true);
}
@Override
public void paint(final Graphics g) {
this.render();
}
public void render() {
if (this.strategy == null) {
return;
}
do {
do {
this.g2d =
(Graphics2D)this.strategy.getDrawGraphics();
this.drawBox();
this.g2d.dispose();
if (!this.strategy.contentsRestored()) {
break;
} else {
System.out.println(### BUFFER CONTENTS
RESTORED ###);
}
} while (true);
this.strategy.show();
if (!this.strategy.contentsLost()) {
break;
} else {
System.out.println(### BUFFER CONTENTS LOST
###);
}
} while (true);
}
@Override
public void update(final Graphics g) {
this.paint(g);
}
private void drawBox() {
this.g2d.setColor(Color.RED);
this.g2d.fillRect(20, 20, this.getWidth() - 40,
this.getHeight() - 40);
}
}
[/code]
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Final version of VSync available...
For your testing purposes -- http://pancyl.com/VSync.htm Source: http://pancyl.com/java/vsync/VSyncApplet.java http://pancyl.com/java/vsync/VSyncCanvas.java http://pancyl.com/java/vsync/VSyncFS.java === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Join images (tiles) with low memory footprint
Yeah, I'd like to know that one too... [EMAIL PROTECTED] wrote: I have the following problem: I try to join many tile images into a big image using BufferedImage and then storing it as PNG or JPG. Memory usage is linear - for 4000x4000 pixel result image (16,000,000 pixel) I need 16 times more memory than for a 1,000,000 pixel image. Do you know a method of joining small images into a large image using a constant memory footprint? Any hints will be appreciated. Best, Marcin [Message sent by forum member 'mgryszko' (mgryszko)] http://forums.java.net/jive/thread.jspa?messageID=285971 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] What is the proper way to compare drawing a BufferedImage and drawing an Image with BufferStrategy?
In a test applet, I can draw a BufferedImage or an Image using
BufferStrategy. Drawing with BufferStrategy is more than 3
times faster than just a straight drawImage() with a BufferedImage.
Am I doing a proper comparison? I thought BufferedImage's did
all the acceleration for you. Or was that just the double buffering?
What is a more true way to compare the drawing?
Here's the paint() method:
public void paint(Graphics g)
{
//System.err.println(paint());
try
{
if(!this.isShowing())return;
g.drawImage(bufferedImage,0,0,thisW,thisH,this);
//do {
//do {
//bg = (Graphics2D)bs.getDrawGraphics();
//bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
//bg.dispose();
//} while (bs.contentsRestored());
//bs.show();
//} while (bs.contentsLost());
}
catch (Exception ie)
{
ie.printStackTrace();
}
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] vertical synchronization in full screen exclusive mode problem
My latest version of VSyncApplet toggles between the use of Image and BufferedImage for simple drawing. Both are rendered to the screen with BufferStrategy. I see disturbing results. BufferedImages are half as fast as Image for simple drawing. I'm probably doing something wrong. Any improvement in the code will be appreciated. The code: http://pancyl.com/java/vsync/VSyncApplet.java http://pancyl.com/java/vsync/VSyncCanvas.java http://pancyl.com/java/vsync/VSyncFS.java http://pancyl.com/VSync.htm Enter fullscreen mode -- F1 Exit fullscreen mode -- ESC === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] vertical synchronization in full screen exclusive mode problem
I think you misunderstand my intentions. The applet shows a profound defect in the Java2D API. Either the applet is wrong or the Java2D API needs work. I'm trying to illuminate the problem with my applet. If the applet uses the Java2D API wrong when I use standard programming strategies, then let's figure out why and fix it. If you think you are contributing to a constructive dialog with your comment then maybe you should rethink your perspective. Or not. I really don't care much what you think. [EMAIL PROTECTED] wrote: BufferedImages are half as fast as Image for simple drawing. I'm probably doing something wrong. Any improvement in the code will be appreciated. After repeatedly insulting the Java2D team members that were trying to have a constructive dialog, i wouldn't hold my hopes too high. [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=285466 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] vertical synchronization in full screen exclusive mode problem
Do you feel like posting the whole code? I'd like to
turn it into an applet for test purposes. It
would be an excellent test program.
I'll repost it as an applet.
You can email it to me direct at:
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi all,
I can get vertical synchronization in full screen exclusive mode with JDK1.5
but not with JDK1.6. I am using the strategy outlined at
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html. I
tested this on two systems and the outcome is the same. The systems are:
System 1:
OS: Linux-x86_64 (Fedora 8)
Graphics card: NVidia Quadro FX 570M
NVIDIA Driver Version: 173.14.09
X Server: Xorg version 1.3.0.0
System 2:
OS: Linux-x86 (Ubuntu 8.04)
Graphics card: NVidia GeForce Go 6400
NVidia driver version: 169.12
X Server: Xorg 1.4.0.90
I tested the same code on these two systems enabling/disabling opengl pipeline
(-Dsun.java2d.opengl=True/False) and with jdk1.5 and jdk1.6. The only
combination where I get the correct behavior is jdk1.5 and opengl pipeline
enabled (on both systems). (Note on a Windows XP machine it works with both
JDK1.6 and 1.5)
Here is a part from the code:
createBufferStrategy(2);
bs = getBufferStrategy();
for (int j = 0; j nRepeat; j++)
for (int i = 0; i = getWidth() - bi.getWidth(); i += bi.getWidth())
displayImage(i, y, bi);
...
public void displayImage(int x, int y, BufferedImage bi) {
do {
do{
Graphics g = bs.getDrawGraphics();
g.setColor(getBackground());
g.fillRect(0, 0, getWidth(), getHeight());
g.drawImage(bi, x, y, null);
g.dispose();
}while(bs.contentsRestored());
bs.show();
}while(bs.contentsLost());
}
Expected outcome is a bar smoothly moving from left to right (bi is just that,
a vertical bar) on a black background.
Any ideas? Thank you.
[Message sent by forum member 'boyaci' (boyaci)]
http://forums.java.net/jive/thread.jspa?messageID=285070
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Pushing int[] pixel data into Image
The absolute fastest way is to first stay away from BufferedImage. Use MemoryImageSource. It's real easy to use -- as opposed to BufferedImage which nobody really understands and takes 10 steps to do one simple thing. Make an image using MemoryImageSource then use BufferStrategy (not BufferedImage) to render to the screen. [EMAIL PROTECTED] wrote: I have an int array where each element represents the RGB value for a pixel and I need to push that data into an image buffer (which is preferably a VolatileImage but may be a BufferedImage if using a VI for this is not possible) such that a subregion of the image buffer takes on the pixels in the int array. What's the best way to achieve this in the absolute fastest possible way? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] I need to apply a convolution kernel to an array of int's...
I'm looking for a way to apply a simple convolution kernel to an array of int's representing the RGB of an image. I've looked at Graphics2D. It has a setTransform() method but only allows an affine transform -- scale,rotate,shear etc. I've looked at ConvolveOp but it only takes BufferedImages, Rasters and WriteableRasters as arguments. The native ops for ConvolveOp are in the sun.awt.image.ImagingLib class but the methods for ImagingLib only take BufferedImages,Rasters and WriteableRasters. I can write the convolution calculation myself but that will be cow slow in execution. I want hardware acceleration on the convolution if I can get it. So I'm stuck. Does anyone know of a secret sun.awt.* class that would do convolutions on a simple int array? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] What is the fastest way to draw a small portion of a BufferedImage?
I need to draw just a small rectangular portion of a BufferedImage. What is the absolute best, fastest way to do that? Is their a tutorial that will show how to do that. Note that this is a different task than before. There will be no projection done on that rectangular part of the BI. It will be just a straight draw to the screen. For example: Let's say I have a 1000 x 1000 pixel image and I just want to draw the portion starting at x = 200, y = 200, width = 100, height = 100 Is using public abstract boolean drawImage(Image img, int dx1, int dy1, int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, Color bgcolor, ImageObserver observer) the best way or is there another best way in the ...new imaging API... === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] I need a way to decode an image file directly into a byte or i
Thanks, I've done that and am getting much better performance
than previously.
ba = ((DataBufferByte)(bi.getRaster().getDataBuffer())).getData();
pixels = new int[width*height];
for(int i = 0,j = 0; i pixels.length; i++,j+=3)
{
pixels[i] = 0xff00 | (((ba[j+2] 0x00ff) 16) | ((ba[j+1]
0x00ff) 8) | (ba[j] 0x00ff));
}
Now I'm exploring
ri = reader.readAsRenderedImage(0, param);
But this stuff is really dense and convoluted. It would probably
make more sense to me if I took a hit of LSD but...
[EMAIL PROTECTED] wrote:
But this whole experiment still leads me back to ask
for a way to
decode an image directly into an integer array like I
first asked.
Something like pixels =
imageReader.decodeFileBytesToIntegerArray(...)
But all I seem to get from you is ...rewrite the
applet... Ok.
Ken, don't rewrite applet, just add conversion (just a few lines of code) from
byte array(s) to int array.
This is really an inexpensive operation.
Andrey
[Message sent by forum member 'imagero' (imagero)]
http://forums.java.net/jive/thread.jspa?messageID=275567
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Prototype applet using BufferedImage...
If I do this to get the pixels from an image for later rendering in a
MemoryImageSource my applet runs fine.
width = image.getWidth(canvas);
height = image.getHeight(canvas);
pixels = new int [width * height ];
int cnt = 0;
pg = new PixelGrabber(image,0,0,width,height,pixels,0,width);
try
{
while (pg.grabPixels(0) != true)
{
Thread.yield();
}
if ((pg.getStatus() ImageObserver.ABORT) != 0)
{
System.err.println(Image fetch aborted or errored...);
}
}
If I do this -- then the applet becomes sluggish to the point
of not being usable.
int [] pixels = null;
try
{
ImageInputStream iis = ImageIO.createImageInputStream(new
ByteArrayInputStream(imageBuffer));
Iterator readers = ImageIO.getImageReadersByFormatName(jpg);
ImageReader reader = (ImageReader)readers.next();
ImageReadParam param = reader.getDefaultReadParam();
bi = new BufferedImage(1024,1024,BufferedImage.TYPE_INT_RGB);
param.setDestination(bi);
reader.setInput(iis, true);
bi = reader.read(0,param);
width = bi.getWidth();
height = bi.getHeight();
pixels =
((DataBufferInt)(bi.getRaster().getDataBuffer())).getData();
}
Does this have something to do with the way integer arrays
are stored? Is there indirection involved somewhere.
I've attached my entire class file for your inspection.
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
package pantile;
import java.awt.*;
import java.io.*;
import java.net.*;
import java.util.*;
import java.awt.color.ColorSpace;
import java.awt.image.DataBufferInt;
import java.awt.image.PixelGrabber;
import java.awt.image.ImageObserver;
import javax.imageio.*;
import javax.imageio.stream.*;
import java.awt.image.BufferedImage;
public class PanTileImageFetch implements Runnable
{
private URL imageURL = null;
private PanTileCanvas canvas = null;
private PanTileProjector projector = null;
private PanTileApplet applet = null;
private final int CHUNKSIZE = 1024;
public byte[] imageBuffer = null;
public InputStream in = null;
public int numRead = 0;
public int size = 0;
public boolean cache = true;
private int [] pixels = null;
private PixelGrabber pg = null;
private Image image = null;
public PanTileImageFetch(PanTileApplet a)
{
applet = a;
}
public void setImageURL(URL u)
{
imageURL = u;
}
public void setCanvas(PanTileCanvas c)
{
canvas = c;
}
public void setProjector(PanTileProjector p)
{
projector = p;
}
public boolean FIRSTIMAGELOADED = false;
public boolean READKILL = false;
public boolean getImageBytes()
{
int numRead = 0;
int offset = 0;
if(PanTileApplet.DEBUG) System.err.println(getImageBytes()...);
try
{
URLConnection urlConnection = imageURL.openConnection();
//urlConnection.setConnectTimeout(8000);
//if(canvas != null)
//{
//canvas.paintCachingIndicator(Loading., FIRSTIMAGELOADED);
//}
//if(cache)
//urlConnection.setUseCaches(true);
//else
//urlConnection.setUseCaches(false);
//urlConnection.setReadTimeout(8000);
size = urlConnection.getContentLength();
if(size = 0)
{
if(canvas != null)
{
canvas.KILLCACHINGINDICATOR = true;
canvas.paintMsgScreen(Image zero length...,false);
}
return false;
}
imageBuffer = new byte[size];
in = urlConnection.getInputStream();
if(PanTileApplet.DEBUG) System.err.println(Starting Read...);
while((numRead = in.read(imageBuffer,offset,imageBuffer.length - offset)) != -1)
{
//if(PanTileApplet.DEBUG) System.err.println(Bytes Read = + numRead);
if(READKILL) return false;
offset += numRead;
if(offset = imageBuffer.length)
{
byte[] temp = new byte[imageBuffer.length + CHUNKSIZE];
System.arraycopy(imageBuffer, 0, temp, 0, offset);
imageBuffer = temp;
}
Thread.yield();
}
//if(canvas != null)
//{
//
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
I just thought of something. What is the alpha channel set to when the BufferedImage is created and the databuffer is extracted? If the alpha channel is 0, that would explain a lot. That means the image is transparent. There's two stages of rendering. The first stage only does nearest neighbor interpolation. The second stage does a bi-cubic interpolation and I explicitly initialize the alpha channel to 0xff to make the image not transparent. Ken Warner wrote: Hi Jim, I'm not communicating the step by step procedure for the projection I guess. It's not like you describe. There is no massaged data. It's just a pixel map that I take a portion of and calculate a gnomic projection. If I had a white board I could draw a diagram that explains everything. It's a realtime (sort of) projection. Anyway, here's the two different versions of the applet I promised. One uses PixelGrabber the other uses BufferedImage. This is the performace problem I'm seeing. I always take the blame for something like this until proven otherwise. So I must be doing something wrong but the code is so simple I just don't see where. http://pancyl.com/BufferedImage.htm http://pancyl.com/PixelGrabber.htm PixelGrabber works ok for a prototype. BufferedImage is a mystery yet. You have the source to the class where the problem is. If you have time to take a look at makeBuffereImage() and maybe you will see something I don't. Ken Jim Graham wrote: Hi Ken, Do you really need to rewrite it all the way through? For example, the massaged data (that has been run through the panoramic projection) could be stored in integer format - it's just the code that reads a pixel out of the source tiles that needs to change, but any intermediate storage and the final storage that you use could be integer-based. I'd have to see the conversion code to make any suggestions beyond these guesses... ...jim Ken Warner wrote: I'll try that. Using bi = reader.read(0,param); PanTile Testbed 1813 1031 1001 982 941 981 1002 971 Using bi = reader.read(0) -default reader PanTile Testbed 1081 601 291 330 261 270 300 280 Using PixelGrabber etc. PanTile Testbed 1432 1221 1272 1112 1141 1081 1101 1092 Clearly the default reader is faster by a lot -- except the data is not in a format I can use in the current version. The current version of the apple is only expected to download one image so I wasn't much concerned with that piece of code. A version loading tiles is another thing. But the code would have to be re-written all the way through to the final paint loop. Because I use integer arrays everywhere. Maybe it would be worth the effort if I could be sure that the final performance was really going to be much faster than it is now. The rendering would have to be significantly faster to make the re-write really worth the effort. And while I have been resistent to the idea of using BufferedImages -- I will do anything to make my applet faster. But given that the applet is stable and fairly well tuned using integer arrays, I'm not likely to re-write it using the three byte databuffer to save 800ms per 1meg tile. Tiles will most likely be even smaller. *And the performance slowdown is after I get the pixels from the databuffer.* After the int [] pixels is assigned to, all the other code remains the same except I see this unexplained slow down in user interaction. If I can figure that problem out (with your help) then it might be worth the re-write. [stuff deleted] === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
Whatever... The image was not being drawn because the alpha channel was 0x00. Initializing the alpha channel to 0xff allowed us to see the image. I don't have a lot of energy for a big discussion about this. But this whole experiment still leads me back to ask for a way to decode an image directly into an integer array like I first asked. Something like pixels = imageReader.decodeFileBytesToIntegerArray(...) But all I seem to get from you is ...rewrite the applet... Ok. I think I'm done. Jim Graham wrote: The MemoryImageSource relies on the ColorModel to define whether or not the data contains an alpha channel. If you use one of the MIS constructors that does not take a ColorModel object then those constructors are specifically specified to use the default RGB ColorModel as defined by the ColorModel.getRGBdefault() method which specifies 8 bits of alpha. I'm not sure what you mean when you say that it means it's transparent to [...] BufferStrategy since that object doesn't deal with pixel storage formats... ...jim Ken Warner wrote: Maybe it doesn't mean the BufferedImage is transparent but 0x00 in the alpha channel of a pixels means it's transparent to the MemoryImageSource and BufferStrategy. Jim Graham wrote: The 3byte databuffer has no storage available for an alpha value. When the data is loaded into the TYPE_INT_RGB BufferedImage there is no alpha stored there since that is an opaque type. More specifically, if you load one of the integers from the underlying int[] pixel array of such an image the upper 8 bits are undefined and should be ignored - if those bits are 0 then that does not mean that the pixel is transparent, and if they contain a 0xff value then that is just a lucky coincidence as those bits are not explicitly tracked or initialized by any code that deals with that image type... ...jim Ken Warner wrote: I just thought of something. What is the alpha channel set to when the BufferedImage is created and the databuffer is extracted? If the alpha channel is 0, that would explain a lot. That means the image is transparent. There's two stages of rendering. The first stage only does nearest neighbor interpolation. The second stage does a bi-cubic interpolation and I explicitly initialize the alpha channel to 0xff to make the image not transparent. Ken Warner wrote: Hi Jim, I'm not communicating the step by step procedure for the projection I guess. It's not like you describe. There is no massaged data. It's just a pixel map that I take a portion of and calculate a gnomic projection. If I had a white board I could draw a diagram that explains everything. It's a realtime (sort of) projection. Anyway, here's the two different versions of the applet I promised. One uses PixelGrabber the other uses BufferedImage. This is the performace problem I'm seeing. I always take the blame for something like this until proven otherwise. So I must be doing something wrong but the code is so simple I just don't see where. http://pancyl.com/BufferedImage.htm http://pancyl.com/PixelGrabber.htm PixelGrabber works ok for a prototype. BufferedImage is a mystery yet. You have the source to the class where the problem is. If you have time to take a look at makeBuffereImage() and maybe you will see something I don't. Ken Jim Graham wrote: Hi Ken, Do you really need to rewrite it all the way through? For example, the massaged data (that has been run through the panoramic projection) could be stored in integer format - it's just the code that reads a pixel out of the source tiles that needs to change, but any intermediate storage and the final storage that you use could be integer-based. I'd have to see the conversion code to make any suggestions beyond these guesses... ...jim Ken Warner wrote: I'll try that. Using bi = reader.read(0,param); PanTile Testbed 1813 1031 1001 982 941 981 1002 971 Using bi = reader.read(0) -default reader PanTile Testbed 1081 601 291 330 261 270 300 280 Using PixelGrabber etc. PanTile Testbed 1432 1221 1272 1112 1141 1081 1101 1092 Clearly the default reader is faster by a lot -- except the data is not in a format I can use in the current version. The current version of the apple is only expected to download one image so I wasn't much concerned with that piece of code. A version loading tiles is another thing. But the code would have to be re-written all the way through to the final paint loop. Because I use integer arrays everywhere. Maybe it would be worth the effort if I could be sure that the final performance was really going to be much faster than it is now. The rendering would have to be significantly faster to make the re-write really worth the effort. And while I have been resistent to the idea of using BufferedImages -- I will do anything to make my applet faster. But given that the applet is stable and fairly well tuned using
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
I understand the newer imaging API's well enough to know they are awkward and lacking in flexibility and utility. I understand your responses well enough to know when I'm being sandbagged. I understand that any request to do anything different from the Gold Standard of Perfection that exists only in your head is received with disdain. I know that your response to my simple request for a simple enhancement is re-write your code so that we don't have to do any more work. is perfect giant, faceless bureaucratic behavior. Could I expect less? Enjoy your cubicle. Jim Graham wrote: Hi Ken, I'm sorry that you are having trouble understanding the newer imaging APIs as they generally provide facilities that are quite flexible and useful for writing the type of application that you are creating here. The primary missing link would seem to be some documentation that would bridge the gap for you and I have been trying to help you out there with some email conversations behind the scenes. Apparently the frustration there is not worth the gains for you. This may not make sense to you, but your request for a new API to produce the data you want would not streamline the process for the simple fact that you want to work with data in a format that differs from what is generated by the JPEG decoders so some format conversion must occur somewhere. The only conversion free way to get the raw pixel data from the JPEG decoders is to accept it in the 3byte format that they want to generate it in. Your request for a new API would not change that fundamental fact of the JPEG format in any way. The old PixelGrabber code was probably the least efficient way to get the data converted into the format you want. The ImageI/O mechanism you chose, which allows you to specify the format of the generated BufferedImage is more efficient than the PixelGrabber method per your own image reading benchmarks. Apparently it had some negative interaction with the rest of the code which I was hoping to help you figure out, but it is hard for me to debug such problems via email without seeing the rest of the code. Adapting your code to the inherent storage format used by the JPEG decoders (the 3byte format) is the only way to eliminate the loading overhead. We aren't being lazy or obstinate here Ken. Just because you can write pseudo-code for your desired API doesn't mean it will magically implement itself with zero overhead. It won't happen. If you do not wish to understand the underlying flow of pixel data enough to understand that, then feel free to live with the overhead of whichever mechanism you find most easy to use. As you pointed out in an earlier email the image decoding step is far from the most important player in your process, so worrying about speeding up the rest of the process would probably be more fruitful in the long run anyway. Good luck! ...jim Ken Warner wrote: Whatever... The image was not being drawn because the alpha channel was 0x00. Initializing the alpha channel to 0xff allowed us to see the image. I don't have a lot of energy for a big discussion about this. But this whole experiment still leads me back to ask for a way to decode an image directly into an integer array like I first asked. Something like pixels = imageReader.decodeFileBytesToIntegerArray(...) But all I seem to get from you is ...rewrite the applet... Ok. I think I'm done. Jim Graham wrote: The MemoryImageSource relies on the ColorModel to define whether or not the data contains an alpha channel. If you use one of the MIS constructors that does not take a ColorModel object then those constructors are specifically specified to use the default RGB ColorModel as defined by the ColorModel.getRGBdefault() method which specifies 8 bits of alpha. I'm not sure what you mean when you say that it means it's transparent to [...] BufferStrategy since that object doesn't deal with pixel storage formats... ...jim Ken Warner wrote: Maybe it doesn't mean the BufferedImage is transparent but 0x00 in the alpha channel of a pixels means it's transparent to the MemoryImageSource and BufferStrategy. Jim Graham wrote: The 3byte databuffer has no storage available for an alpha value. When the data is loaded into the TYPE_INT_RGB BufferedImage there is no alpha stored there since that is an opaque type. More specifically, if you load one of the integers from the underlying int[] pixel array of such an image the upper 8 bits are undefined and should be ignored - if those bits are 0 then that does not mean that the pixel is transparent, and if they contain a 0xff value then that is just a lucky coincidence as those bits are not explicitly tracked or initialized by any code that deals with that image type... ...jim Ken Warner wrote: I just thought of something. What is the alpha channel set to when the BufferedImage is created
[JAVA2D] [Fwd: [PanoToolsNG] Billion-pixel panoramas]
This is what I'm talking about. The current fleet of Java panorama viewers can display images usually less than 5000x2500 pixels -- more depending on the compression level. The default memory settings for the current plugin are the biggest limiting factor. And many panographers view Java as being too slow compared to Flash. Flash is the preferred deployment platform because it is more widely installed on the desktop and doesn't seem to suffer from the severe memory limitations of the current plugin. Also, people think Flash is faster simply because it starts faster. A mis-conception in my view. What I'm trying to do with my applet is to try to service modestly bigger panoramas -- perhaps 1x5000 or a little bigger depending on how rapidly the next generation plugin is deployed. Achievable goals is my moto... I hope you guys are planning for this kind of applet/application. Cause if you aren't, Flash is really going to eat your lunch. Original Message Subject: [PanoToolsNG] Billion-pixel panoramas Date: Thu, 15 May 2008 11:05:33 -0700 (PDT) From: dtonnes [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Drudgereport.com has this headline: Prepare for the billion-pixel camera..., it links to this article: http://technology.timesonline.co.uk/tol/news/tech_and_web/article3938717.ece - it's about the gigapan project. When Drudge links to something, a lot of people read it. One cannot help but come to the realization that our once-esoteric type of photography is becoming more pedestrian. -- View this message in context: http://www.nabble.com/Billion-pixel-panoramas-tp17259113p17259113.html Sent from the PanoToolsNG mailing list archive at Nabble.com. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] [JAI-IMAGEIO] [Fwd: [PanoToolsNG] Billion-pixel panoramas]
By the way, my applet also does orthographic projections. http://pancyl.com/ball.htm Bob Deen wrote: Hi Ken... You might look at JadeDisplay, which is an image display component designed to work well with tiles and very large images. It may or may not meet your needs but we recently released it Open Source (BSD-style license): http://www.openchannelfoundation.org/projects/JadeDisplay Let me know if you find it useful. -Bob Deen @ NASA-JPL Multimission Image Processing Lab [EMAIL PROTECTED] Ken Warner wrote: This is what I'm talking about. The current fleet of Java panorama viewers can display images usually less than 5000x2500 pixels -- more depending on the compression level. The default memory settings for the current plugin are the biggest limiting factor. And many panographers view Java as being too slow compared to Flash. Flash is the preferred deployment platform because it is more widely installed on the desktop and doesn't seem to suffer from the severe memory limitations of the current plugin. Also, people think Flash is faster simply because it starts faster. A mis-conception in my view. What I'm trying to do with my applet is to try to service modestly bigger panoramas -- perhaps 1x5000 or a little bigger depending on how rapidly the next generation plugin is deployed. Achievable goals is my moto... I hope you guys are planning for this kind of applet/application. Cause if you aren't, Flash is really going to eat your lunch. Original Message Subject: [PanoToolsNG] Billion-pixel panoramas Date: Thu, 15 May 2008 11:05:33 -0700 (PDT) From: dtonnes [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Drudgereport.com has this headline: Prepare for the billion-pixel camera..., it links to this article: http://technology.timesonline.co.uk/tol/news/tech_and_web/article3938717.ece - it's about the gigapan project. When Drudge links to something, a lot of people read it. One cannot help but come to the realization that our once-esoteric type of photography is becoming more pedestrian. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] I need a way to decode an image file directly into a byte or integer array...
Something is getting lost in the translation -- When I say directly I mean directly from the file bytes into a byte or integer array without first making an Image or a BufferedImage. *Something* like this (and I know it doesn't exist so don't get excited) int [] pixels = Toolkit.createPixelArray(fileBytes,...); Something like that. Notice that I don't make an Image or BufferedImage first. That's what I think would be a useful addition to the greater image handling api. Now to all those who are gnashing your teeth about why I don't want to use BufferedImages -- take a valium and have a beer and a ciggy -- relax and let me live in my own little world without BufferedImages. Jim Graham wrote: Hi Ken, ImageI/O reads images into a BufferedImage which provides easy access to a Java int/byte array with the pixels. Details of pixel access for BufferedImage objects were discussed recently on this thread: http://forums.java.net/jive/thread.jspa?messageID=269294 ...jim Ken Warner wrote: I think there is a hole in the greater Java API for working with images. Images and BufferedImages are great if all you want to do is download [stuff deleted] === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] I need a way to decode an image file directly into a byte or integer array...
I think there is a hole in the greater Java API for working with images. Images and BufferedImages are great if all you want to do is download an image file and put it on the screen. They are really good at that. But if someone (like myself) needs to work at a lower level -- at the pixel level to prepare and synthesize pixels for display, the existing API's are way too complicated. There is no way to read an image file -- jpg, tif, png, whatever -- and simply decode that image file into a byte or integer array. You always have to ask for an image of one sort or another to be created. And that is not a straight forward procedure either. If you use the Toolkit to make your image, you have to make a MediaTracker to wait for the image to be made somewhere deep in the JVM. Then, if you want to manipulate the pixels of the image directly either to change the color or position of a particular pixel or to generate a new set of pixels, you have to either ask the image for the pixel or use a PixelGrabber to ask the image for it's pixels in either byte array or integer array form. If you use a PixelGrabber, again you have to wait for an ImageProducer to deliver the pixels in the array of your choice. And that process has to be carefully minded to make sure it completes. It would be so much simpler if I could just decode an image file directly into a byte or integer array. I'm starting a new project where I will be rendering huge panoramic images sometimes as big as 50,000x25,000 pixels or even bigger. To do that, I will be downloading tiles from the panorama as needed on demand. The image will be made into a manageable set of tiles by other tools. There may even be a set of tiles at different resolutions for the same panorama. So for each tile I have to download the image file, make an image and watch over that process with a MediaTracker and after the Image is made, make a PixelGraber to grab the pixels and watch over that process then when I have (in my code) integer array -- I throw all that stuff away (flush the image resources etc.) and do the whole thing over again for the next tile. Maybe ImageIO Tools has a way to do that but now that's a separate download and install and until the next generation plugin -- which will simplify silent installs of extra packages -- is widely deployed , not an option. I don't know of a way to simply decode an image file into a byte or integer array. I hope that there really is a way and I'm just not aware of it. I don't mind being dumb. I'm dumb a lot. So if anyone knows a way to decode an image file directly into a byte or integer array, please tell me how to do it. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why does BufferedImage setRGB consumes memory?
I hope MemoryImageSource is not going to be depricated!!! I use it big time in all my applets. What would be the replacement for MemoryImageSource? I hope you aren't thinking that BufferedImage is better. BufferedImage is a giant, poorly thought out hairball... [EMAIL PROTECTED] wrote: The memory-leaking behavior is not relevant for me anymore since I changed the implementation to MemoryImageSource already, but I am still curious if anyone has an idea why setting pixels consumes that much memory. I would really recommend not using MemoryImageSource. Its an API from the java-1.1 days and its not recommended to use it any further. Its just there for compatibility reasons. Setting large amount of pixels using setRGB is not a good practise, best way is to directly grab the raster from a BufferedImage: [code] byte[] data=((DataBufferByte)tex.getRaster().getDataBuffer()).getData() [/code] this is for a byte-backed BufferedImage, but looks almost the same for an int[] one (which I recommend for best performance). lg Clemems [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=269294 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why does BufferedImage setRGB consumes memory?
One Raster? When I went through the same problem, I had to do that three times to get the R,G,B channels. [EMAIL PROTECTED] wrote: [code]byte[] data=((DataBufferByte)tex.getRaster().getDataBuffer()) .getData() [/code] looks like there is a lot of casting involved. I can see only one. [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=269313 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Premature end of JPEG file
I'm getting this bazarre error message when I exit my applet. It doesn't show until *AFTER* the applet has had it's destroy() method called. I do not issue this error message in my code and don't know where to look in the Java source to figure out what to do about it. It's harmless but annoying and I think that some method somewhere is hanging and not finalizing after the read. I read two jpg files -- create the images using the Toolkit and watching them with MediaTracker. I remove the Image ID's from the MediaTracker and then grab the pixels with a PixelGrabber. Then I flush() the images and null all the instances and call System.runFinalization() and then System.gc() The applet runs fine and then when I exit, I get two weird error messages. Premature end of JPEG file Premature end of JPEG file I don't know where to look to figure this out. Anybody have any ideas? Environment: Java 1.5.0.9 Win2K SP4; Eclipse 3.2 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Alpha blending performance
The simple answer is don't draw into the JPanel -- draw into one of Java's image classes (Image, BufferedImage, etc.) and then draw the Image into the JPanel. Then save the Image as a jpeg in the usual ways... Olsen Chris wrote: Hello All -- I have what is probably a simple problem to you all, but is so far baffling me, a statistics guy doing programming. I am hoping that someone may have actually done what I am trying to do. At the end of some serious mathematical calculations (logistic regression) I generate a graph in a JPanel. My problem is that I might do this a few hundred times for a given run of the program. What I want to do is save the contents of _each_ graph as a jpeg rather than do lots of screen captures. In preparation for coding I have been learning a bit about IMAGEIO, etc., but am stumped about one aspect of my anticipated process: how do I get the contents of a content pane into an image format? I am assuming that I can't just cast it somehow; I am also assuming that I cannot simply draw to an image the same way that I draw to the content pane. (These assumptions may be wrong??) I did run across a forum where someone said that they had not done it, but it SHOULD work in practice and then gave a strategy for doing it. Is there anyone who HAS done this and could offer a general strategy? I am OK with the coding before and after the panel contents -- image step. (Strategy much appreciated, sample code that works adored!) References to the literature are fine also... Thank you in advance. -- Chris Chris Olsen H.S. Math / Assessment Facilitator Educational Service Center 346 2nd Ave. SW Cedar Rapids, IA 52404-2099 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] 6uN-b10: 2D Performance regression -or- problems enabling D3D pipeline
I think the v-sync is a great idea. If done properly, it could solve a lot of the tearing problems that unsynced repeated drawing can cause I have this thought. What if the fastest a program can prepare an image for render is less than the frame sync time? Will there be a way to draw fewer frames a second than the vertical sync speed but still have them sync'd with the refresh? Or will that just happen automatially? [EMAIL PROTECTED] wrote: Ah, nice to hear it's all working! Is there any way to manage v-sync from within Java, and if not, are there any plans to add such a feature? Enabling v-sync in windowed mode could save performance as those extra frames aren't all that useful anyways, and some may want v-sync disabled in full screen mode. Thank you for all of your fast replies and great support, it is very much appreciated. [Message sent by forum member 'ejoakim' (ejoakim)] http://forums.java.net/jive/thread.jspa?messageID=254552 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Possible bug in Fullscreen Exclusive mode -- Java 1.6.0_5-ea
Environment:
Microsoft Windows 2000 [Version 5.00.2195] SP4
Java Plug-in 1.6.0_05-ea
Using JRE version 1.6.0_05-ea Java HotSpot(TM) Client VM
URL:
http://pancyl.com/
http://pancyl.com/gnomic.htm
In the first URL, if you go fullscreen, the Java Applet Window banner is
displayed.
When I go fullscreen on the second URL, the banner is now missing. It's
exactly the same code. The banner is replaced by a void. I get the insets
and subtract the bottom inset to calculate the projection of the image
correctly.
But on the first URL, the banner is displayed. On the second the banner is
missing.
Is this the bug that was refered to earlier?
The only significant difference is that in the first applet I do not write
to the browser status line. In the second URL I do write to the status line
each time the window is drawn.
Notice the browser status line as you press and release the mouse button.
Here's the method for going fullscreen:
public void setFullScreenMode(boolean b)
{
//System.err.println((1)Ignore Repaint = + this.getIgnoreRepaint());
this.setIgnoreRepaint(true);
this.setCursor(applet.getStopCursor());
Insets inset = null;
try
{
if(b)
{
//System.err.println(Going Full Screen...);
projector.ABORT = true;
gdFS.setFullScreenWindow(this);
pgfs = this;
this.setBounds(0, 0, 1400, 1200);
fsW = gdFS.getDisplayMode().getWidth();
fsH = gdFS.getDisplayMode().getHeight();
inset = getInsets();
fsH -= inset.bottom;
System.err.println(height = + fsH);
if(misFS == null)
{
//System.err.println(New MemoryImageSource...);
pixelsFS = new int [fsW * fsH];
misFS = new MemoryImageSource(fsW, fsH, ColorModel.getRGBdefault(), pixelsFS, 0, fsW);
misFS.setAnimated(true);
misFS.setFullBufferUpdates(true);
imageFS = this.createImage(misFS);
}
this.createBufferStrategy(2);
bsFS = this.getBufferStrategy();
projector.setFullScreenMode(this,pixelsFS,fsW,fsH);
//System.err.println(7);
}
else
{
projector.ABORT = true;
//System.err.println(Disposing Frame...);
imageFS.flush();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
this.dispose();
}
}
catch(OutOfMemoryError oome)
{
oome.printStackTrace();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
applet.handleOutOfMemoryError();
this.dispose();
}
catch (Exception e)
{
e.printStackTrace();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
this.dispose();
}
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Odd Vista, NVidia, dual-display, Java interaction...
My applet goes fullscreen exclusive. Don't know if an applet will do you any good http://pancyl.com F1 enters; ESC exits fullscreen exclusive... [EMAIL PROTECTED] wrote: Reposted from http://weblogs.java.net/blog/chet/archive/2006/10/java_on_vista_y.html on Dmitri's suggestion... So here's an interesting problem, related to - if not directly caused by - Java on Vista. Brand new machine (Lenovo T61p T7700, 4GB, NVidia Quadro FX 570M driving 1680x1050 LCD, Vista Ultimate 32-bit from Microsoft GM DVD - not the Lenovo pre-install), with Java 1.6.0_03. When docked (but not when not docked), I run it in a dual-monitor configuration (add on a 1600x1200 external display via DVI). Two or three times a day, the machine simply turns off when I am switching to or from the Java application (Interactive Brokers trade station started via .jnlp download through Firefox). If I don't have the IB Java app running, the machine works flawlessly. If I run the IB Java app undocked (ie, just the 1680x1050 LCD driven), no problem. Seems like an odd interaction between the display driver and Java. I'm running the NVidia 7.15.11.5685 drivers dated 12/10/07. Again, it's not a BSOD. The machine simply and instantaneously powers off. Java itself, I hope, cannot do that, but the display driver might be able to cause such a serious fault. Any thoughts? Dmitri has suggested I try a different Java app and the latest build of 6uN, which I'll do. I'll add that I run the Java app full screen (which, in a dual display environment, means only 1 screen - the 1600x1200 screen, which is below the 1680x1050 screen). As I don't have any other Java apps that I routinely run, I'm willing to try any Java apps anyone thinks might be best for this kind of trial. Thanks, Richard [Message sent by forum member 'rrelph' (rrelph)] http://forums.java.net/jive/thread.jspa?messageID=252272 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Possible bug in Fullscreen Exclusive mode -- Java 1.6.0_5-ea
Environment:
Microsoft Windows 2000 [Version 5.00.2195] SP4
Java Plug-in 1.6.0_05-ea
Using JRE version 1.6.0_05-ea Java HotSpot(TM) Client VM
URL:
http://pancyl.com/
http://pancyl.com/gnomic.htm
In the first URL, if you go fullscreen, the Java Applet Window banner is
displayed.
When I go fullscreen on the second URL, the banner is now missing. It's
exactly the same code. The banner is replaced by a void. I get the insets
and subtract the bottom inset to calculate the projection of the image
correctly.
But on the first URL, the banner is displayed. On the second the banner is
missing.
Is this the bug that was refered to earlier?
The only significant difference is that in the first applet I do not write
to the browser status line. In the second URL I do write to the status line
each time the window is drawn.
Notice the browser status line as you press and release the mouse button.
Here's the method for going fullscreen:
public void setFullScreenMode(boolean b)
{
//System.err.println((1)Ignore Repaint = + this.getIgnoreRepaint());
this.setIgnoreRepaint(true);
this.setCursor(applet.getStopCursor());
Insets inset = null;
try
{
if(b)
{
//System.err.println(Going Full Screen...);
projector.ABORT = true;
gdFS.setFullScreenWindow(this);
pgfs = this;
this.setBounds(0, 0, 1400, 1200);
fsW = gdFS.getDisplayMode().getWidth();
fsH = gdFS.getDisplayMode().getHeight();
inset = getInsets();
fsH -= inset.bottom;
System.err.println(height = + fsH);
if(misFS == null)
{
//System.err.println(New MemoryImageSource...);
pixelsFS = new int [fsW * fsH];
misFS = new MemoryImageSource(fsW, fsH, ColorModel.getRGBdefault(), pixelsFS, 0, fsW);
misFS.setAnimated(true);
misFS.setFullBufferUpdates(true);
imageFS = this.createImage(misFS);
}
this.createBufferStrategy(2);
bsFS = this.getBufferStrategy();
projector.setFullScreenMode(this,pixelsFS,fsW,fsH);
//System.err.println(7);
}
else
{
projector.ABORT = true;
//System.err.println(Disposing Frame...);
imageFS.flush();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
this.dispose();
}
}
catch(OutOfMemoryError oome)
{
oome.printStackTrace();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
applet.handleOutOfMemoryError();
this.dispose();
}
catch (Exception e)
{
e.printStackTrace();
gdFS.setFullScreenWindow(null);
projector.setCanvasMode();
this.dispose();
}
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Question about fullscreen exclusive mode in applet in browser...
Can I exploit that bug too? :-)
But seriously, all the users I have contact with find
that status bar real annoying. Annoying to the point that
they are willing to look to Flash or other means to display
their panoramas. They are a fussy group and I struggle to
maintain Java's relevance to that group.
So does the Java2D group have any say about the status
bar or should I talk to another development group.
No need to grind on you if it's not in your purview...
Dmitri Trembovetski wrote:
HOW DID THEY DO THAT??? Is this another secret environment variable?
I would like to know how to go into fullscreen mode without the status
bar showing.
I think they may be exploiting a bug fixed in the latest
versions.
On my jre (6uN) the window does show the warning.
Thanks,
Dmitri
Ken Warner wrote:
Hi,
My applet at
http://pancyl.com
can go into fullscreen exclusive mode. F1 enters -- ESC exits.
When it goes into fullscreen exclusive mode using the 1.6 plugin,
there is a gray status bar at the bottom of the screen that says,
Java Applet Window A lot of people find this annoying. Fullscreen
exclusive should mean
FULLSCREEN! I've looked at java.awt.GraphicsDevice and this is the
method that
set's the bounds of the window.
public void setFullScreenWindow(Window w) {
// Get display mode before changing the full screen window
DisplayMode dm;
if (w == null) {
dm = null;
} else {
dm = getDisplayMode();
}
if (fullScreenWindow != null windowedModeBounds != null) {
fullScreenWindow.setBounds(windowedModeBounds);
}
// Set the full screen window
fullScreenWindow = w;
if (fullScreenWindow != null) {
windowedModeBounds = fullScreenWindow.getBounds();
fullScreenWindow.setBounds(0, 0, dm.getWidth(),
dm.getHeight());
fullScreenWindow.setVisible(true);
fullScreenWindow.toFront();
}
}
I tried to write my own class to extend GraphicsDevice so I can
override setFullScreenWindow()
but I can't put it into the java.awt package. I get a security
warning at runtime.
I'm not smart enough or good enough to figure out a way to set the
bounds of the fullscreen window so that the status bar won't show.
However, someone has. Goto the URL below. You will see a gallery
of available panoramic images. They can be shown in Flash, Java or
Quicktime. Select one to show in Java. When you see that it's finished
loading, click the right button and enter fullscreen mode. You will see
that there is no status bar.
HOW DID THEY DO THAT??? Is this another secret environment variable?
I would like to know how to go into fullscreen mode without the status
bar showing.
http://easypano.com/panorama-gallery.html
Ken
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Question about fullscreen exclusive mode in applet in browser.
All valid arguments. And I'm sure I don't know any of the grizzly stories about how Java is/was being used for fraud. It's a hoist petard situation -- damned if you do -- damned if you don't. Having Java become suspect as an easy tool for fraud certainly won't do us developers any good. Yet people object to having their precious fullscreen so rudely violated. I'll meander over to the security and awt talklists and see what I can see. And it's a banner not a status bar... [EMAIL PROTECTED] wrote: Hi Ken, The problem is you have to think of all of this from a different perspective. Don't think I'm a nice responsible developer who wants to make a pretty app... Think I'm an identity stealer and I want to fool the user into giving me their credit cards and other personal information. A disclaimer for the following text. We aren't security experts here on the Java2D forum. We just like to draw pretty pictures. I'll give some clarifications below to make sure you've considered the possibilities that I'm aware of that led to the creation of the applet banner, but I don't want to launch into a debate here in this forum on the issues. Probably the best place to discuss issues related to Java security and windows would be either the AWT or the security areas. Java2D isn't involved at all in putting the warning up (we probably don't even render it as it is likely a native component). What I would suggest is putting a small 16x16 Java icon in the upper left corner of the full screen window. That's he conventional place for identification via icons. And erhaps clicking on the icon could escape fullscreen exclusive mode. Consider how this looks to a user on an identity stealing page. Oh, how nice that these nice folks at PayPalSecurity.NG implemented their Identity Verification page in Java. Someone should talk to them about their grammar, though - it's atrocious. There needs to be a clear message that tells uninformed users not to provide any identity information, not just this is Java since few people outside of our developer communities really understands what Java can do for fraud perpetrators. The idea of a status bar is not evil. But it should be under the control of the programmer. The visibility, color, message should be under the control of the applet. I'm sure the folks at SeeNigeria.net would love to control how that status bar looks. Perhaps a nice black text on black background color scheme would be prettier - tone on tone is such a big fashion statement these days. ;-) The status bar could be enabled for other purposes like a menu bar or tool bar. Then there would be some useful purpose to it that would override the annoyance factor. In some sense, the annoyance factor is its main advantage when it comes to security. Also, there should be a choice of top or bottom or invisible. If invisible, then show the icon in the upper left corner. Again, if we don't do this banner, then we need something that is an obstacle to identity theft. We aren't the experts on these issues here in the Java2D forum - you should probably raise the discussion as to what the security banner does and what better or alternate solutions could provide the same benefits on either the Security or AWT forums... ...jim [Message sent by forum member 'flar' (flar)] http://forums.java.net/jive/thread.jspa?messageID=248338 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] fillPolygon performance versus drawImage
Hi Gregory, Do all your rectangle drawing to an off screen image. The image can be any thing from a Toolkit image to a BufferedImage to a VolitileImage. Each one has advantages. Then draw the off screen image to the screen. Your mileage may vary... [EMAIL PROTECTED] wrote: Hi, This is probably a naive question... I need to display a frequently varying rectangles, that can have different size and color. A typical size of an individual rectangle is about 5 by 5 pixels, but there can be up to 100x110 rectangles per display (a typical bitmap display). I need to display it from with a JComponent. My big question is: what is the fastest way to do it? I can either loop over the number of rectangles and each time call Graphics.fillRect(), or I can create an image using MemoryImageSource followed by createImage and eventually Graphics.drawImage() function. Which one (or a different method) shall I use? Also, where can I find information about how Graphics.fillRect() work? Does this function fills in an array of pixels with one color, and then creates an object equivalent to an image, so in essence it is the same as calling drawImage? Or is the mechanism completely different? Thank you Gregory [Message sent by forum member 'gmiecznik' (gmiecznik)] http://forums.java.net/jive/thread.jspa?messageID=248161 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] [PanoToolsNG] Layout test
This is SUN's new Security Measure. When Java goes full screen, they put that stupid gray status bar underneth. As a Java programmer, I know of no way to keep that from happening. There are no doc's at SUN that even tells you that will happen when you go fullscreen. HOWEVER: EasyPano Java viewer seems to be able to get around that problem. It can go fullscreen without showing that stupid status bar. http://www.easypano.com/panorama-gallery.html# Try their Java viewer. The full screen switch is on a right button menu. I'm cross posting this message to one of SUN's development forums. I suggest that any of you who are concerned about Java's utility as a panorama viewer platform to join that forum and complain to that forum. Ken Warner Notes. In the middle of the layout proces a new Sun Java was installed on my PC - and due to some new security restrictions Immervisions fullscreen won't do real fullscreen anymore. The applet window doesn't cover the Start-meu bar and it has a grayish bar with the text Java Applet Window. I have reported it to the Immervision team and they are looking into it to see if they can do anything about it. Flemming V. Larsen wrote: Hi I've made 3 different layout tests showing hi-res panos with thumbnail-selection and the plugin-detect script from DevalVR. http://fvlmedia/pdep/layouttest.php?tema=faroeF It works and looks fine here on my winxp pro PC both with IE6 an Firefox ( with some small differents) on a 1152 x 864 screen on a 17 monitor a. I would like if those of you using other browsers and/or other OS could test and report if there is something not working. (In IE 6 I'm able to set the colours of the scroll-bar via CSS. It doesn't work in FF - How about other browsers?) b. From mac-users with Pangea installed I would like to hear if the Auto-detect use Pangea (and perharps see a screen shot) c. From those of you using bigger screen-size I'd also like to know if the thumbnails gets to small and/or if you think I should make some restrictions to the window-size? (The panos are generated from 5100 x 2550 equirectangular, so there might be an upper limit where it doesn't look good anymore) Notes. In the middle of the layout proces a new Sun Java was installed on my PC - and due to some new security restrictions Immervisions fullscreen won't do real fullscreen anymore. The applet window doesn't cover the Start-meu bar and it has a grayish bar with the text Java Applet Window. I have reported it to the Immervision team and they are looking into it to see if they can do anything about it. I have used Pano2Qtvr to do the flash - I know that Flash Panorama Player gives a better quality and I might use it in the future. Best regards Flemming === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA-- another stupid question...
I thought the first notice that was sent out about the D3D pipeline said that the OpenGl pipeline was turned on for D3D. I must have misunderstood what was said. The D3D pipeline and the OpenGL pipelines are two different pipelines with two entirely different sets of problems mostly caused by poorly implemented video card drivers. Am I finally understanding this? And the OpenGL pipeline has nothing to do with the hardware acceleration of Java2D which uses the D3D pipeline? Is that correct? So it was said that the D3D pipeline will be disabled *BY DEFAULT* on some OS's. Will it be possible to *ENABLE* the D3D pipeline with -Dsun.java2d.d3d=true on the Win200* OS's that are going to have the D3D pipeline disabled by default from using the D3D pipeline? In all the emails that have been flying around, people talk of ...the pipeline... and I get confused about which pipeline is being talked about. Dmitri Trembovetski wrote: Just in case this hadn't been replied to: yes, we'd seen this behavior on certain video boards only on Vista with Aero enabled. I'm pretty sure this is a Vista bug, but we'll try to work around it. Thanks, Dmitri [EMAIL PROTECTED] wrote: Hello, I've been playing a few hours with the 6u5 and the D3D pipeline. (I'm quite sure it is enabled, as a full-screen drawing framerate drops by a factor of about 20 when disabled, with CPU usage jumping to about 70%) Marvelous performance (thank you all for your work), however I have found something annoying : (I did my tests on Windows Vista, with an nVidia GeForce 8600M GT, recent drivers (Aero enabled)) If I create an empty resizable JFrame (I tested with SystemLookAndFeel, SubstanceLookAndFeel and Metal), and start resizing it, I will most of the time see its content flickering (the client rectangle becoming black before being repainted). Obviously, all reverted to normal when I ran the application with -Dsun.java2d.d3d=false. Someone has an idea about what is happening ? [Message sent by forum member 'artscoop' (artscoop)] http://forums.java.net/jive/thread.jspa?messageID=245249 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Saving restoring a region of a VolatileImage
Dmitri once sent me a link to the docs for BufferStrategy. There's an example loop there that works -- IF YOU ARE USING BufferStrategy. For just VI -- try the forums I guess http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html The loop described in the docs work for me pretty well. But I'm using BufferStrategy. [EMAIL PROTECTED] wrote: Hi flar, Thanks for the info. I like the speed I am getting using VIs and if they all fail together then that's not a problem. But I would like to ensure that I am using them in 100% correct way so that I can recover from any losses. Is the JavaDoc sufficient info on best practices for programming with VI? Is there a link that gives example code of exactly how and when to check for content loss? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Saving restoring a region of a VolatileImage
That's what I've found. That render loop is almost instantaneous while the pixel pushing takes two orders of magnitude more time. [EMAIL PROTECTED] wrote: It is unlikely that the graphics creation and disposal would cost you any noticeable amount of time, especially compared to everything else that is going on. It's a lot cleaner to just create and dispose the graphics around the rendering portion of the method than to try to manage a cached copy. [Message sent by forum member 'flar' (flar)] http://forums.java.net/jive/thread.jspa?messageID=247279 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Dumb question about Direct?????
Sorry for the dumb question but I see references to DirectDraw, DirecX and Direct3D. Could someone briefly describe the difference between the three and what exactly is Java doing with regard to using DirectDraw, DirectX and Direct3D? Which one is being used for the OpenGL pipeline? === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Dumb question about Direct?????
So then the line in the sand (so to speak) is whether or not the graphics card (driver) supports OpenGL to it's full extent? Yes? No? If there is not good support for OpenGL on the host machine, then Java's OpenGL pipeline will fail? Yes? No? So then this is not about the OS as earlier stated. It's about support for OpenGL by the graphic card's driver? Yes? No? [EMAIL PROTECTED] wrote: DirectX = The whole collection of APIs for different game-related tasks like DirectInput for input handling, Direct3D for 3D graphics, ... DirectDraw = 2D programming interface, now deprecated. Direct3D = 2D/3D interface offered by DirectX. The OpenGL pipeline uses OpenGL and does not use DirectX at all. Because of this fact its able to work on so many operating systems whereas the D3D pipeline is limited to Windows-Systems only. lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=246977 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA
More stupid design strategy decisions by SUN. Who thinks up these strategies? And then the rational that is expressed to support those stupid decisions are next to priceless. What ever you do -- never listen to the people who actually try to use Java. I give up. And while I know nobody at SUN is interested in the fact that whole communities are turning to Flash for graphics and think Java sucks big time. I care! I've got nearly 10 years of Java programming that nobody wants because they hold Java in such low regard. Dmitri Trembovetski wrote: First of all, FYI, b07 is out. It has a couple of important fixes - it significantly improves performance of Netbeans (and other applications which use LCD and grayscale AA text simultaneously) and addresses issues on Intel chips. Ken Warner wrote: I have an NVida GeForce2 GTS/GeForce2 Pro Driver Version 3.15.00.12.00 Running Windows 2000 SP4 and DirectDraw 9.0c -- real old stuff and yet the most current version of the driver and Java 1.6 is about 3 times faster than 1.5. There are two issues here: GF2 does not meet minimum hw requirements so the pipeline will be disabled. You will need at least some GeForce FX board (with Shaders 2.0) with HW Transform and Lighting. Secondly, starting with b08 the pipeline will only be enabled on client-class OS (WinXP and newer). Win2K* are classified as a server-class OS flavor. The reason for this policy is that typically on servers people care more about stability than performance, and the drivers for these systems are lagging behind client OS-es. Thanks, Dmitri It's hard for me to run the beta version to test hardware acceleration. Have their been any reports about this card failing? When will there be a 1.6 JRE with hardware acceleration so I can try my work -- it's an applet. [EMAIL PROTECTED] wrote: Thanks! I have filed bug 6629891: D3D: Rendering artifacts with older driver [Nvidia Quadro NVS 110M] to track this issue (will appear on bugs.sun.com soon). We'll disable the pipeline on drivers older than 6.14.11.5665 (earliest known to work at this point). Thanks, Dmitri [Message sent by forum member 'trembovetski' (trembovetski)] http://forums.java.net/jive/thread.jspa?messageID=245499 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Saving restoring a region of a VolatileImage
I use the BufferStrategy as an interface to VolitileImage and it works great in my applet. I don't make VolitileImage's directly in my code. Dmitri Trembovetski wrote: It would be interesting to find out what was causing the freeze. Would it be possible to create a small test case reproducing the issue? Or if you could just show a piece of code which was using VolatileImages? Thanks, Dmitri Java2D Team [EMAIL PROTECTED] wrote: Excellent Dmitri - thank you. I have it working now though not for a VolatileImage, I had to use a BufferedImage instead. This is because using the VI caused my applet to freeze when running inside the browser even though it runs OK when run inside the Eclipse applet viewer. Well I guess that's good enough - it has improved my applet considerably. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Saving restoring a region of a VolatileImage
I use a Canvas. I'll send you my Canvas class code if you want to see how I do it. Might not make sense because I do all the pixel pushing stuff in another class. [EMAIL PROTECTED] wrote: Ken, how do you create the BufferStrategy in your applet? It seems from the JavaDoc that you need a Window or Canvas. I have neither of those in my applet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Three D mouse / navigator / spaceball --- would it work with Java?
It would be a neat thing to be able to pan/tilt/zoom with one device. http://www.3dconnexion.com/3dmouse/spacenavigator.php === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Saving restoring a region of a VolatileImage
No, what you described is a computation that is not facilitated by the use of BufferStrategy and VolitileImage. They are for getting what you have computed on the screen -- fast. [EMAIL PROTECTED] wrote: Hi Ken, Yes, I would love to see how you use the strategy even though it's probably not going to be appropriate for me given that I have a requirement to save subregions of the buffered image which are restored later. I can't see how I can easily do this with a BufferStrategy but I could be wrong. Just email me with the code if you like - the addy is at the bottom of this message. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?
[quote] Then have higher level layers of graphic acceleration for the more advanced video cards. Shading etc. [/quote] Well I think some kind of black-listing would probably the best thing - black-list which driver/os/directx-versions are known to be broken and emit a small warning on the command line about that (this way many more people will complain at gpu manufacturers to provide better drivers). If that leads to more people getting some kind of hardware acceleration -- I support that idea. What you mean would be really hard to implement - in fact this would lead to many different implementations for each GPU generation. Who should pay all the programmers and bug-fixers ;) Not if it is done right. Really hard is what those 6 figure salaries are for. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?
The funny thing is that Windows 2000 wasn't a server class OS when I bought it. It was just the latest Windows. Somewhere along the line it became a server OS. And I didn't know I became an Administrator. I guess I didn't get the memo. And the reason I don't upgrade to XP or (yuk) Vista is that I'd rather spend my cycles on work rather than fancy icons and animation to give me a ...richer user interface experience... Windows 2000 is almost as fast as Windows NT I guess it's just a matter of perspective. And there's no point in telling Microsoft anything -- they know *ALL* the answers. It's not my fault! Dmitri Trembovetski wrote: Ken Warner wrote: The assumption that, ...typically people don't care about graphics performance on a server, and also drivers tend to be old/buggy on servers as they are not updated as often. Is fundamentally wrong -- at least in my case. You may want to tell that to Microsoft then, because in their next server os (Windows 2008) not only Aero is disabled by default, it is not even present in the installation, and the default (and only) theme is Win2k. I guess they have found that administrators don't care much about fancy graphics on servers. Moreover, the vast majority of servers are administered remotely anyway. Thanks, Dmitri === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?
I'm just going by what Dmitri told me... Secondly, starting with b08 the pipeline will only be enabled on client-class OS (WinXP and newer). Win2K* are classified as a server-class OS flavor. The reason for this policy is that typically on servers people care more about stability than performance, and the drivers for these systems are lagging behind client OS-es. Thanks, Dmitri Phil Race wrote: Ken, Please read the subject line. Windows 2003 and 2008 are server OSes and are quite different than windows 2000. -phil. Ken Warner wrote: The funny thing is that Windows 2000 wasn't a server class OS when I bought it. It was just the latest Windows. Somewhere along the line it became a server OS. And I didn't know I became an Administrator. I guess I didn't get the memo. And the reason I don't upgrade to XP or (yuk) Vista is that I'd rather spend my cycles on work rather than fancy icons and animation to give me a ...richer user interface experience... Windows 2000 is almost as fast as Windows NT I guess it's just a matter of perspective. And there's no point in telling Microsoft anything -- they know *ALL* the answers. It's not my fault! Dmitri Trembovetski wrote: Ken Warner wrote: The assumption that, ...typically people don't care about graphics performance on a server, and also drivers tend to be old/buggy on servers as they are not updated as often. Is fundamentally wrong -- at least in my case. You may want to tell that to Microsoft then, because in their next server os (Windows 2008) not only Aero is disabled by default, it is not even present in the installation, and the default (and only) theme is Win2k. I guess they have found that administrators don't care much about fancy graphics on servers. Moreover, the vast majority of servers are administered remotely anyway. Thanks, Dmitri === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?
One last thing then I'll say no more. Seems to me that the way to include / exclude systems is by the capabilities of the graphics card that Java is running on. I can think of server side apps that could use a fast graphics pipeline to ship chunks of graphical information to a client using a high speed network. You have the big iron running the graphics and the client displaying the computed image. Things like molecular physics; GIS systems; animations; VR -- stuff like that where the heavy lifting was done server side and the client was just watching. Also if someone didn't fit the profile you've described and put a really good graphics card in a server and then found out that the graphics card was not used by Java because of the OS -- that person might get a little upset. But I think I will say no more Dmitri Trembovetski wrote: That's correct, Windows 2000 will also be excluded. Thanks, Dmitri Ken Warner wrote: I'm just going by what Dmitri told me... Secondly, starting with b08 the pipeline will only be enabled on client-class OS (WinXP and newer). Win2K* are classified as a server-class OS flavor. The reason for this policy is that typically on servers people care more about stability than performance, and the drivers for these systems are lagging behind client OS-es. Thanks, Dmitri Phil Race wrote: Ken, Please read the subject line. Windows 2003 and 2008 are server OSes and are quite different than windows 2000. -phil. Ken Warner wrote: The funny thing is that Windows 2000 wasn't a server class OS when I bought it. It was just the latest Windows. Somewhere along the line it became a server OS. And I didn't know I became an Administrator. I guess I didn't get the memo. And the reason I don't upgrade to XP or (yuk) Vista is that I'd rather spend my cycles on work rather than fancy icons and animation to give me a ...richer user interface experience... Windows 2000 is almost as fast as Windows NT I guess it's just a matter of perspective. And there's no point in telling Microsoft anything -- they know *ALL* the answers. It's not my fault! Dmitri Trembovetski wrote: Ken Warner wrote: The assumption that, ...typically people don't care about graphics performance on a server, and also drivers tend to be old/buggy on servers as they are not updated as often. Is fundamentally wrong -- at least in my case. You may want to tell that to Microsoft then, because in their next server os (Windows 2008) not only Aero is disabled by default, it is not even present in the installation, and the default (and only) theme is Win2k. I guess they have found that administrators don't care much about fancy graphics on servers. Moreover, the vast majority of servers are administered remotely anyway. Thanks, Dmitri === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Direct3D is disabled in win2003 in 6uN EA?
The assumption that, ...typically people don't care about graphics performance on a server, and also drivers tend to be old/buggy on servers as they are not updated as often. Is fundamentally wrong -- at least in my case. I keep my machine as up to date as possible. I installed the most recent driver for my old video card -- before NVidia stopped supporting it. And I have the latest DirectDraw that Microsoft has released for Windows 2000. I understand that some time in the future, my machine will simply be an old useless hulk but it's still got a lot of useful life left in it. My suggestion would be to support hardware acceleration in layers. The lowest level layer would be the basic hardware acceleration for VolitileImage so that basic use of BufferStrategy would give hardware acceleration for simple drawing -- if the card supported that. BufferStrategy already does a check to see basic capabilities of the card. Then have higher level layers of graphic acceleration for the more advanced video cards. Shading etc. I don't even know what the most advanced cards have these days. The idea being to do the best you can with the capabilities of the card Java is running on. As the old saying goes: Don't let perfect stand in the way of good. Ken Dmitri Trembovetski wrote: The reason is that typically people don't care about graphics performance on a server, and also drivers tend to be old/buggy on servers as they are not updated as often. If you have an opinion or use case on why this should not be the case please let us know. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Full screen exclusive mode question...
Good suggestions...I'll give those a try. Be nice if it was just gone. I mean how silly... [EMAIL PROTECTED] wrote: Hmm, I haven't checked this, but can't you find the size of the drawable area through a combination of things like getContentPane().getSize() (If its a swing window) and frame.getInsets() or frame.getSize()? Not sure which if any will work yet. [Message sent by forum member 'fred34' (fred34)] http://forums.java.net/jive/thread.jspa?messageID=240256 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Full screen exclusive mode question...
http://pancyl.com/debug.htm It goes full screen exclusive mode now. F1 to enter -- ESC to exit. Someone tell me how it works with D3D acceleration. I can't run the beta version of 1.6 right now. Question/Problem: When in full screen mode in a browser, there is a little status line that says: Java Applet Window But there is no documentation that I can find about that status line. This is metioned in passing in the Full Screen Exclusive Mode tutorial -- http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html For security reasons, the user must grant fullScreenExclusive permission when using full-screen exclusive mode in an applet. Which does a pretty good job of explaining how to set things up but you really don't have to do that if you are willing to suffer that little status line apparently. What I want to know is how do I find out how high is the status line at runtime so I can adjust my render accordingly. It may be small but it's still a chunk of pixels that I don't need to render if they are just going to be drawn over. Also, it would be nice to be able to use that area for controls and status when in full window mode. And having that status line really does absolutly nothing to enhance security. I suppose that's the reason for it. Lastly, I have observed that the Frame which is the full window area sometimes loses the ignoreRepaint() value. When that happens, a system generated repaint can cause flashing so I set it everytime I enter my render method. You can see in the console the value of getIgnoreRepaint() I print out each time through my render method and each time I fall in and out of full screen mode. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] How do I install the 1.6 beta as my browser plugin?
Hi, I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar to try D3D acceleration. When I install it, there is no installation as browser plugin. I imagine this is intentional. Is there a way to force it to be a browser plugin? I would like to see real world performance in the browser. I tried jre-6u5-ea-windows-i586-p-iftw.exe and that gives me about a three time performance boost in general computation and about a 1/3'd performance boos in drawing. I'd like to compare the beta in the same environment. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] How do I run my applet in the 1.6 beta?
There's no applet viewer and I didn't put a static main() in my applet. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] How do I install the 1.6 beta as my browser plugin?
Ok, massive confusion and loss of brain cells I have installed: Java Plug-in 1.6.0_05-ea I don't have a particular need to diddle with the registry right now as outlined in the forum pointed to in Dmitri's last post. I get a pretty good boost in performance with 1.6.0_05-ea. But there is no D3D acceleration in this release -- right? D3D is only in ...05-ea-b04 -- right? So I'll wait to test D3D acceleration in my applet when the install is more straight forward. In the mean time, all you guys can use my applet as a standard comparison test -- if you want. http://pancyl.com/debug.htm It prints out times for a computational task and a painting task in the console. Here's some results I got on an 800 mhz machine with an old GeForce 2 video card. Java Plug-in 1.6.0_05-ea Using JRE version 1.6.0_05-ea Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\Administrator PanCyl v0.3.2_D3DTest Interp Time = 521ms Paint Time(640, 360) = 50ms --- Interp Time = 451ms Paint Time(640, 360) = 30ms --- Interp Time = 250ms Paint Time(640, 360) = 30ms --- Interp Time = 270ms Paint Time(640, 360) = 20ms --- Interp Time = 230ms Paint Time(640, 360) = 20ms --- Interp Time = 230ms Paint Time(640, 360) = 30ms --- Interp Time = 230ms Paint Time(640, 360) = 20ms --- Interp Time = 230ms Paint Time(640, 360) = 30ms --- Interp Time = 261ms Paint Time(640, 360) = 30ms --- Interp Time = 241ms Paint Time(640, 360) = 20ms --- Interp Time = 230ms Paint Time(640, 360) = 20ms --- Interp Time = 230ms Paint Time(640, 360) = 20ms --- Java Plug-in 1.5.0_11 Using JRE version 1.5.0_11 Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\Administrator PanCyl v0.3.2_D3DTest Interp Time = 861ms Paint Time(640, 360) = 50ms --- Interp Time = 590ms Paint Time(640, 360) = 30ms --- Interp Time = 601ms Paint Time(640, 360) = 30ms --- Interp Time = 591ms Paint Time(640, 360) = 30ms --- Interp Time = 591ms Paint Time(640, 360) = 30ms --- Interp Time = 581ms Paint Time(640, 360) = 30ms --- Phil Race wrote: I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar SFAIK this is just a self-extracting jar file that dumps the files on disk - its not an installer. You must use one of the installer downloads - eg the .exe download -phil. Ken Warner wrote: Hi, I downloaded jre-6u5-ea-bin-b04-windows-i586-27_sep_2007.jar to try D3D acceleration. When I install it, there is no installation as browser plugin. I imagine this is intentional. Is there a way to force it to be a browser plugin? I would like to see real world performance in the browser. I tried jre-6u5-ea-windows-i586-p-iftw.exe and that gives me about a three time performance boost in general computation and about a 1/3'd performance boos in drawing. I'd like to compare the beta in the same environment. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Ok -- what's the deal on the spyware in Java 1.6?
Ah! I guess I'm just paranoid - Thanks -- I forgot to turn off the auto download. Russell East wrote: Isn't that just the Update Notification feature? You can disable it in the Control Panel. -- Russell Ken Warner wrote: Ever since I installed 1.6 yesterday, my firewall has been detecting this connection attempt: C:\Program Files\Java\jre6\bin\jusched.exe TCP (Outbound) 72.5.124.55: http(80) It happens frequently -- like hourly -- I block the attempt. I don't like being spyed on. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Ok -- what's the deal on the spyware in Java 1.6?
Ever since I installed 1.6 yesterday, my firewall has been detecting this connection attempt: C:\Program Files\Java\jre6\bin\jusched.exe TCP (Outbound) 72.5.124.55: http(80) It happens frequently -- like hourly -- I block the attempt. I don't like being spyed on. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA
http://pancyl.com/debug.htm
I've put some timing code in my applet. It may be useful to do a comparison
between 1.5 and 1.6 with the D3D acceleration on your own machine.
What you will see in the console window is --
PanCyl v0.3.2_D3DTest
Interp Time = 841ms
Paint Time(640, 360) = 50ms
---
Interp Time = 591ms
Paint Time(640, 360) = 30ms
---
Interp Time = 611ms
Paint Time(640, 360) = 30ms
---
What you are looking at is the time to interpolate a 640x360 image (my own
bicubic interpolator -- it's slow) and then the time to paint that 640x360
image in a Canvas.
Here's the rendering method that is in MyCanvas. I only use paint() for system
events. mis is a MemoryImageSource; bs is the BufferStrategy; bg is the
BufferStrategy Graphics
//this is what is timed
t1 = System.currentTimeMillis();
System.err.println(Interp Time = + (t1 - t0) + ms);
t2 = System.currentTimeMillis();
canvas.newPixels();
t3 = System.currentTimeMillis();
System.err.println(Paint Time( + canvasW + , + canvasH + ) = + (t3 -
t2) + ms);
System.err.println(---\n);
public void newPixels()
{
try
{
if(!this.isShowing())return;
do {
do {
bg = (Graphics2D)bs.getDrawGraphics();
mis.newPixels(0,0,thisW,thisH,true);
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
if(DRAWATT)
drawAttribution(); // ignore this
bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());
}
catch (Exception ie)
{
ie.printStackTrace();
}
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Update N: Framerate degrades markedly
I offer this just to try and be helpful. I have an applet that uses VolitileImages throught the BufferStrategy interface. It creates images using a MemoryImageSource. Then it drawImage() onto the BufferStrategy graphics and does a BufferStrategy show(). The show() is in the canonical BufferStrategy drawing loop, checking to see if the buffer graphics has changed. My development computer is down for repairs. Does anyone want to do a side by side comparison with 1.5 and the new 1.6? I'm on an NT box now and 1.6 is not compatible with NT -- or so it says when I try to load it. It's about a 1.4meg image so if you are on a slow connection, it may take some time. When my development computer gets fixed, I'll put in some timing print out so you can compare time to paint. The debug output in the console now only shows time to render the image bytes not the drawing times so they are irrelevant. You would have to do a side by side comparison to see differences. But there might be some obvious bugs show. Drag the mouse and spin the wheel to pan and zoom. But here's the URL anyway if someone finds it useful: http://pancyl.com/debug.htm [EMAIL PROTECTED] wrote: I tried the new Update N with one of my Java applets and the framerate has degraded markedly. I can confirm the Direct3D pipeline is enabled (see listing at the end of this post), and that if I use -Dsun.java2d.d3d=false everything goes back to normal (eg. fast and smooth). Admittedly this applet is a few years old, but it has always been fine under JDK1.4, Java 5 and Java 6 up until now. You can try it for yourself at: http://www.play500online.com/500/500.jsp (and click 'Start New') I am happy to send a copy of the source to the team if you can give me the best e-mail address. In brief though, it is all Java2D, transparency, clipping, anti-aliasing and VoltaileImages. Regards, Richard [EMAIL PROTECTED] === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0? -- slowness fixed
Jim, EXCELLENT! I need to do a couple of things then. 1) Check to see if the multiplication by the basis functions can possibly lead to the kind of values that can possibly cause the kind of overflow problems you describe. I think they might. 2) Generate a test case for the code you provided and post results. The premultiplication problem will not be an issue for my little interpolator since I do not composite. But it would be for someone trying to use my interpolator for another purpose than what it was designed for. The reason for the existence of my interpolator is that the primary function of my cylindrical panorama viewer is to project (the best I can) a cylindrical image into a rectified viewport. Interpolation before or after the projection simply doesn't work so the interpolator is integrated into the projection code. It would have been real nice to be able to hand off a chunk of the cylindrical image to a Java2D bi-cubic interpolator and get a nicely interpolated rectified viewport but that is impossible. The corners of the source image chunk are stretched in a non-linear fashion to fit the canvas. It's not a simple resize. But this is really interesting information. And maybe someday someone will ask me about it and I can sound smart... :-) Ken Jim Graham wrote: All of this discussion happened while I was away on vacation. The code that came up was pretty much what I tend to use for clamping without branches, but there are a couple of things to note for this particular application: It's only valid for values that overflow in the range MININT=511 and it only clamps to the output range 0=255. The reason for the first constraint is that c23 only sets the high order bit if the overflow stays under 512. If you get up to 512 then the 9th bit is clear again and the clamp to 255 part fails. (Though, it will also correctly clamp values between 768 and 1023 and every other 256-sized range of overflow values up to MAXINT - i.e. the ones that manage to have the 9th bit set...) The reason for the second constraint is because of the assumptions in how the math was constructed. The first constraint may not be a problem if the Cubic Interpolation values can never cause the value to sum up to 2x the maximum value for a component which is probably true, but depends on the cubic formula used to generate the interpolation coefficients (there are a few such formulas in common use) and so needs to be proven for a given formula. The second constraint doesn't seem like a problem if you are always dealing with 8-bit values which is very typical for today's computer graphics, except for one issue which has been ignored. The issue is that image interpolation should really be done in a premultiplied form - as should alpha compositing. The reason for this is that if you blend the 4 components (Alpha, R, G, and B) separately in a non-premultiplied form then a transparent pixel with a non-zero value in, say, its red component will contribute some red tinting to the final answer even though it was transparent and should not have contributed any energy in the first place. Java2D, for example, does linear and cubic interpolation internally in the premultiplied form in the Graphics2D implementation for this reason. Why is this an issue for the clamping equations? The reason is that if your accumulation values are premultiplied then the alpha component needs to be clamped to 0=255, but the color components need to be clamped to the range 0=alpha. The different range on the clamping of the color components means that the proposed equations won't work if you perform your calculations in the premultiplied form. What I've used instead is a sequence of operations that can clamp any input range to an arbitrary 0=N output range as follows: c = ~(c 31); c -= N; c = (c 31); c += N; After the first line c is in the range 0=MAXINT with all negative values mapped to 0. After the second line c is set up so that all valid values are in the range -N=0 and all positive values are overflow values. After the third line all values are in the range -N=0 with the positive values mapped to 0. After the fourth line all values are finally in the range 0=N... (Also, I believe it uses the same number of ALU instructions as the c 23) 31) | c) ~(c31))0xFF formula...) ...jim === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0? -- slowness fixed
It was a localization problem. I was using class variables for all the intermediate channel values. Switching to local variables -- method variables -- I see the slight speed up I was expecting. Example: r3 = (int)p00x00FF) 16)*A0) + (((p10x00FF) 16)*A1) + (((p20x00FF) 16)*A2) + (((p30x00FF) 16)*A3)); g3 = (int)p00xFF00) 8)*A0) + (((p10xFF00) 8)*A1) + (((p20xFF00) 8)*A2) + (((p30xFF00) 8)*A3)); b3 = (int)p00x00FF))*A0) + (((p10x00FF))*A1) + (((p20x00FF))*A2) + (((p30x00FF))*A3)); r3 = r3 23) 31) | r3) ~(r331))0xFF; g3 = g3 23) 31) | g3) ~(g331))0xFF; b3 = b3 23) 31) | b3) ~(b331))0xFF; If r3,g3,b3 are class variables, I see the slowdown. Changing to local variables -- stack variables -- I see a slight improvment. So the triple shift made the interpolation slower (aprox. 1350ms to 1440ms) using class variables. Using local variables I see times like below. So a few milliseconds are saved. It's easy to argue that the time spent engineering is more than the time gained at runtime. I wonder if a place like Pixar would agree. Time = 1302 Waiting... Time = 1302 Waiting... Time = 1322 Waiting... Time = 1292 Waiting... Time = 1312 Waiting... Time = 1302 Waiting... Time = 1352 Waiting... Time = 1312 Waiting... Time = 1292 Waiting... Time = 1302 Waiting... Time = 1302 Waiting... Time = 1302 Waiting... Time = 1422 Waiting... Time = 1412 Waiting... Time = 1342 Waiting... Time = 1292 Waiting... Time = 1302 Waiting... Time = 1292 Waiting... [EMAIL PROTECTED] wrote: In my test suite, the time to interpolate a 944 x 644 image went from 1350ms using the logical test clamp to 1440ms using the triple shift. I'm not sure why... I work on a real slow (800mhz) machine just so I can see these kinds of things better. Could you post that test? Maybe someone can spot what makes the difference. [Message sent by forum member 'rah003' (rah003)] http://forums.java.net/jive/thread.jspa?messageID=231732 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0? -- history and
Yeah, when I integrated it into my bi-cubic interpolator, it slowed it down compared to the logical check clamp. I'm not sure why yet. Maybe it was the way I integrated it. I don't know. In my test suite, the time to interpolate a 944 x 644 image went from 1350ms using the logical test clamp to 1440ms using the triple shift. I'm not sure why... I work on a real slow (800mhz) machine just so I can see these kinds of things better. [EMAIL PROTECTED] wrote: So the clamping is 30 to 40% faster. Did you measure what impact does it have on the overall image processing? How much time does clamping take in the entire computation of the pixel color (with that bicubic interpolation)? Kirill [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=231556 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0? -- history and
Not really, it's the whole applet. I just stick in some timing code to watch sections of it. Just imagine those logical tests replaced by the triple shift. I'll post a snippet tomorrow. See: http://pancyl.com/ [EMAIL PROTECTED] wrote: In my test suite, the time to interpolate a 944 x 644 image went from 1350ms using the logical test clamp to 1440ms using the triple shift. I'm not sure why... I work on a real slow (800mhz) machine just so I can see these kinds of things better. Could you post that test? Maybe someone can spot what makes the difference. [Message sent by forum member 'rah003' (rah003)] http://forums.java.net/jive/thread.jspa?messageID=231732 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0? -- history and solution...
Last week, I asked the question:
What is a trick way to clamp a byte to the range of [0-255] An operation that
is needed all the time in image processing. The common strategy to perform
this operation is usually a logical check of the form:
if(foo 255)foo = 255;
else if(foo 0)foo = 0;
This is basically the clamping strategy in:
com.sun.media.jai.util.ImageUtil.java
public static final byte clampByte(int in) {
return (in 0xFF ? (byte)0xFF : (in = 0 ? (byte)in : (byte)0));
}
James Cheng sent me a snippet from
com.sun.media.jai.opimage.AddOpImage
sum = (s1[s1PixelOffset]0xFF) + (s2[s2PixelOffset]0xFF);
d[dPixelOffset] = (byte)sum23) 31) | sum) 0xFF);
Which clamps the top end to 255 but leaves the bottom end to dangle negative.
Peter West then sent me a mod to the above code --
bar = (foo 23) 31) | foo) 0xFF) ~(foo31))0xFF;
Which clamps the integer to the desired range and is faster quantitatively than
the logical test.
Peter then improved it with a variant to the shift method above by leaving out
the intermediate and trailing mask and cast to byte.
bar = (byte)foo 23) 31) | foo) ~(foo31));
Which quantitatively tests a bit faster.
I've attached the test program used to time the various strategies and post the
results below.
In summary, the triple shift with no intermediate mask is 30% to 40% faster
than the logical test strategy. This can mean a lot when you consider that a
bi-cubic interpolation can have 15 clamping ops per pixel -- that's 15,000,000
clamping ops on a 1K x 1K image.
Below are the test results:
(0)- bar = (foo 23) 31) | foo) 0xFF) ~(foo31))0xFF;
(1)- bar = foo 23) 31) | foo) ~(foo31))0xFF;
(2)- bar = (byte)foo 23) 31) | foo) ~(foo31));
(3)- if(foo 255)foo = 255;
else if(foo 0)foo = 0;
shiftTest()...
0:
(0)Time = 160
(1)Time = 120
(2)Time = 130
(3)Time = 221
1:
(0)Time = 150
(1)Time = 190
(2)Time = 151
(3)Time = 270
2:
(0)Time = 190
(1)Time = 141
(2)Time = 130
(3)Time = 210
3:
(0)Time = 160
(1)Time = 120
(2)Time = 131
(3)Time = 220
4:
(0)Time = 200
(1)Time = 160
(2)Time = 151
(3)Time = 250
5:
(0)Time = 190
(1)Time = 171
(2)Time = 160
(3)Time = 250
6:
(0)Time = 190
(1)Time = 141
(2)Time = 170
(3)Time = 250
7:
(0)Time = 191
(1)Time = 160
(2)Time = 160
(3)Time = 250
8:
(0)Time = 191
(1)Time = 160
(2)Time = 160
(3)Time = 260
9:
(0)Time = 161
(1)Time = 160
(2)Time = 160
(3)Time = 251
10:
(0)Time = 180
(1)Time = 170
(2)Time = 160
(3)Time = 251
11:
(0)Time = 200
(1)Time = 160
(2)Time = 150
(3)Time = 251
12:
(0)Time = 190
(1)Time = 160
(2)Time = 160
(3)Time = 231
13:
(0)Time = 190
(1)Time = 160
(2)Time = 161
(3)Time = 250
14:
(0)Time = 190
(1)Time = 160
(2)Time = 161
(3)Time = 250
15:
(0)Time = 190
(1)Time = 171
(2)Time = 160
(3)Time = 250
16:
(0)Time = 190
(1)Time = 141
(2)Time = 170
(3)Time = 250
17:
(0)Time = 190
(1)Time = 141
(2)Time = 160
(3)Time = 250
18:
(0)Time = 181
(1)Time = 170
(2)Time = 150
(3)Time = 250
19:
(0)Time = 171
(1)Time = 170
(2)Time = 150
(3)Time = 250
20:
(0)Time = 171
(1)Time = 160
(2)Time = 160
(3)Time = 251
21:
(0)Time = 190
(1)Time = 170
(2)Time = 160
(3)Time = 251
22:
(0)Time = 190
(1)Time = 160
(2)Time = 170
(3)Time = 231
23:
(0)Time = 180
(1)Time = 160
(2)Time = 150
(3)Time = 231
24:
(0)Time = 190
(1)Time = 160
(2)Time = 161
(3)Time = 260
25:
(0)Time = 180
(1)Time = 160
(2)Time = 151
(3)Time = 250
26:
(0)Time = 190
(1)Time = 160
(2)Time = 151
(3)Time = 250
27:
(0)Time = 190
(1)Time = 161
(2)Time = 160
(3)Time = 250
28:
(0)Time = 190
(1)Time = 151
(2)Time = 160
(3)Time = 260
29:
(0)Time = 180
(1)Time = 160
(2)Time = 160
(3)Time = 250
30:
(0)Time = 191
(1)Time = 160
(2)Time = 170
(3)Time = 260
31:
(0)Time = 161
(1)Time = 170
(2)Time = 160
(3)Time = 251
32:
(0)Time = 190
(1)Time = 160
(2)Time = 160
(3)Time = 261
33:
(0)Time = 190
(1)Time = 160
(2)Time = 150
(3)Time = 231
34:
(0)Time = 190
(1)Time = 160
(2)Time = 150
(3)Time = 231
35:
(0)Time = 190
(1)Time = 170
(2)Time = 151
(3)Time = 250
36:
(0)Time = 190
(1)Time = 160
(2)Time = 151
(3)Time = 250
37:
(0)Time = 190
(1)Time = 160
(2)Time = 131
(3)Time = 250
38:
(0)Time = 180
(1)Time = 171
(2)Time = 150
(3)Time = 250
39:
(0)Time = 190
(1)Time = 141
(2)Time = 150
(3)Time = 250
40:
(0)Time = 190
(1)Time = 141
(2)Time = 150
(3)Time = 260
41:
(0)Time = 191
(1)Time =
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0?
Hey Peter, it works! Nice job! I'll work it into my code and see
if I get any speed up. I only time to the milliseconds but a millisecond
here -- a millisecond there. Pretty soon it adds up to a decisecond...
int foo = 0;
int bar = 0;
for(int i = -10; i 265; i++)
{
//foo = (i 31) | (i 0xFF);
//foo = (i 0xff);
foo = i;
bar = (foo 23) 31) | foo) 0xFF) ~(foo31))0xFF;
System.err.println(i + : foo = + foo + , bar = + bar );
}
-5: foo = -5, bar = 0
-4: foo = -4, bar = 0
-3: foo = -3, bar = 0
-2: foo = -2, bar = 0
-1: foo = -1, bar = 0
0: foo = 0, bar = 0
1: foo = 1, bar = 1
2: foo = 2, bar = 2
3: foo = 3, bar = 3
.
.
.
252: foo = 252, bar = 252
253: foo = 253, bar = 253
254: foo = 254, bar = 254
255: foo = 255, bar = 255
256: foo = 256, bar = 255
257: foo = 257, bar = 255
258: foo = 258, bar = 255
Ken Warner wrote:
Well, I did a test. The double shift does clamp the top end. But negative
numbers are twisted to be 255. In bi-cubic interpolation (the reason
for all
this nonsense) negative byte (channel) values can occur. The goal is to
clamp to the range [0-255] so -100 goes to 0 and 300 goes to 255.
Here's the snippet:
//sum = (s1[s1PixelOffset]0xFF) + (s2[s2PixelOffset]0xFF);
//d[dPixelOffset] = (byte)sum23) 31) | sum) 0xFF);
int foo = 0;
int bar = 0;
for(int i = -10; i 265; i++)
{
foo = i;
bar = foo 23) 31) | foo) 0xFF);
System.err.println(i + : foo = + foo + , bar = + bar );
}
And here is the abbreviated output:
-4: foo = -4, bar = 255
-3: foo = -3, bar = 255
-2: foo = -2, bar = 255
-1: foo = -1, bar = 255
0: foo = 0, bar = 0
1: foo = 1, bar = 1
2: foo = 2, bar = 2
3: foo = 3, bar = 3
4: foo = 4, bar = 4
.
.
.
252: foo = 252, bar = 252
253: foo = 253, bar = 253
254: foo = 254, bar = 254
255: foo = 255, bar = 255
256: foo = 256, bar = 255
257: foo = 257, bar = 255
258: foo = 258, bar = 255
259: foo = 259, bar = 255
Finally, com.sun.media.jai.util.ImageUtil.java does this to clamp a byte
value
which is equivalent to what I was doing. I need to clamp both ends
reliably.
I wonder if it can be done with shifts and masks? Maybe I've done the best
that can be done.
public static final byte clampByte(int in) {
return (in 0xFF ? (byte)0xFF : (in = 0 ? (byte)in : (byte)0));
}
Ken Warner wrote:
Never mind -- found it...
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19
At run time, shift operations are performed on the two's complement
integer representation of the value of the left operand.
The value of ns is n left-shifted s bit positions; this is
equivalent (even if overflow occurs) to multiplication by two to the
power s.
The value of ns is n right-shifted s bit positions with
sign-extension. The resulting value is � n/2s⌋. For nonnegative values
of n, this is equivalent to truncating integer division, as computed
by the integer division operator /, by two to the power s.
Now if I could only understand this...
[EMAIL PROTECTED] wrote:
if(r 0) r = 0;
if(r 255) r = 255;
if(g 0) g = 0;
if(g 255) g = 255;
if(b 0) b = 0;
if(b 255) b = 255;
Clumsy and awkward. Is there a better way to clamp
the values?
Maybe with a mask or something?
If your better meant faster, you might like to take a look at this:
https://jai-core.dev.java.net/source/browse/jai-core/src/share/classes/com/sun/media/jai/opimage/AddOpImage.java?rev=1.1view=markup
under computeRectByte()
//
// The next two lines are a fast way to do
// an add with saturation on U8 elements.
// It eliminates the need to do clamping.
//
sum = (s1[s1PixelOffset]0xFF) +
(s2[s2PixelOffset]0xFF);
d[dPixelOffset] = (byte)sum23) 31) |
sum) 0xFF);
HTH,
-James
[Message sent by forum member 'jxc' (jxc)]
http://forums.java.net/jive/thread.jspa?messageID=230881
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0?
I did a test -- I did it on a real slow (800mhz) machine so the
differences are magnified but the shift clamp method works a little
faster than the logical test. Enough to include it in my code.
Results at the bottom. And surely enough to be used as the clamping
strategy in:
com.sun.media.jai.util.ImageUtil.java
int foo = 0;
int bar = 0;
long t0 = 0l;
long t1 = 0l;
for(int j = 0; j 100; j++)
{
t0 = System.currentTimeMillis();
for(int i = -1000; i 1000; i++)
{
//foo = (i 31) | (i 0xFF);
//foo = (i 0xff);
foo = i;
bar = (foo 23) 31) | foo) 0xFF) ~(foo31))0xFF;
//System.err.println(i + : foo = + foo + , bar = + bar );
}
t1 = System.currentTimeMillis();
System.err.println((1)Time = +(t1 - t0));
t0 = System.currentTimeMillis();
for(int i = -1000; i 1000; i++)
{
foo = i;
if(foo 255)foo = 255;
else if(foo 0)foo = 0;
//System.err.println(i + : foo = + foo + , bar = + bar );
}
t1 = System.currentTimeMillis();
System.err.println((2)Time = +(t1 - t0));
System.err.println();
}
Ken Warner wrote:
Hey Peter, it works! Nice job! I'll work it into my code and see
if I get any speed up. I only time to the milliseconds but a millisecond
here -- a millisecond there. Pretty soon it adds up to a decisecond...
int foo = 0;
int bar = 0;
for(int i = -10; i 265; i++)
{
//foo = (i 31) | (i 0xFF);
//foo = (i 0xff);
foo = i;
bar = (foo 23) 31) | foo) 0xFF) ~(foo31))0xFF;
System.err.println(i + : foo = + foo + , bar = + bar );
}
-5: foo = -5, bar = 0
-4: foo = -4, bar = 0
-3: foo = -3, bar = 0
-2: foo = -2, bar = 0
-1: foo = -1, bar = 0
0: foo = 0, bar = 0
1: foo = 1, bar = 1
2: foo = 2, bar = 2
3: foo = 3, bar = 3
.
.
.
252: foo = 252, bar = 252
253: foo = 253, bar = 253
254: foo = 254, bar = 254
255: foo = 255, bar = 255
256: foo = 256, bar = 255
257: foo = 257, bar = 255
258: foo = 258, bar = 255
1)Time = 200
(2)Time = 221
(1)Time = 220
(2)Time = 210
(1)Time = 231
(2)Time = 250
(1)Time = 180
(2)Time = 221
(1)Time = 170
(2)Time = 220
(1)Time = 221
(2)Time = 270
(1)Time = 190
(2)Time = 221
(1)Time = 190
(2)Time = 220
(1)Time = 160
(2)Time = 221
(1)Time = 170
(2)Time = 210
(1)Time = 191
(2)Time = 220
(1)Time = 180
(2)Time = 210
(1)Time = 181
(2)Time = 220
(1)Time = 170
(2)Time = 221
(1)Time = 180
(2)Time = 220
(1)Time = 180
(2)Time = 211
(1)Time = 180
(2)Time = 210
(1)Time = 181
(2)Time = 220
(1)Time = 170
(2)Time = 210
(1)Time = 181
(2)Time = 210
(1)Time = 180
(2)Time = 221
(1)Time = 170
(2)Time = 220
(1)Time = 180
(2)Time = 211
(1)Time = 180
(2)Time = 210
(1)Time = 180
(2)Time = 221
(1)Time = 170
(2)Time = 220
(1)Time = 181
(2)Time = 210
(1)Time = 180
(2)Time = 210
(1)Time = 180
(2)Time = 220
(1)Time = 170
(2)Time = 221
(1)Time = 180
(2)Time = 220
(1)Time = 170
(2)Time = 251
(1)Time = 210
(2)Time = 220
(1)Time = 181
(2)Time = 210
(1)Time = 180
(2)Time = 221
(1)Time = 200
(2)Time = 370
(1)Time = 181
(2)Time = 210
(1)Time = 180
(2)Time = 221
(1)Time = 180
(2)Time = 210
(1)Time = 180
(2)Time = 221
(1)Time = 170
(2)Time = 220
(1)Time = 181
(2)Time = 210
(1)Time = 180
(2)Time = 210
(1)Time = 181
(2)Time = 220
(1)Time = 170
(2)Time = 291
(1)Time = 180
(2)Time = 220
(1)Time = 170
(2)Time = 221
(1)Time = 180
(2)Time = 220
(1)Time = 181
(2)Time = 230
(1)Time = 180
(2)Time = 210
(1)Time = 181
(2)Time = 220
(1)Time = 170
(2)Time = 221
(1)Time = 180
(2)Time = 230
(1)Time = 190
(2)Time = 211
(1)Time = 190
(2)Time = 250
(1)Time = 191
(2)Time = 220
(1)Time = 180
(2)Time = 221
(1)Time = 160
(2)Time = 230
(1)Time = 220
(2)Time = 241
(1)Time = 180
(2)Time = 250
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0?
Well, I did a test. The double shift does clamp the top end. But negative
numbers are twisted to be 255. In bi-cubic interpolation (the reason for all
this nonsense) negative byte (channel) values can occur. The goal is to
clamp to the range [0-255] so -100 goes to 0 and 300 goes to 255.
Here's the snippet:
//sum = (s1[s1PixelOffset]0xFF) + (s2[s2PixelOffset]0xFF);
//d[dPixelOffset] = (byte)sum23) 31) | sum) 0xFF);
int foo = 0;
int bar = 0;
for(int i = -10; i 265; i++)
{
foo = i;
bar = foo 23) 31) | foo) 0xFF);
System.err.println(i + : foo = + foo + , bar = + bar );
}
And here is the abbreviated output:
-4: foo = -4, bar = 255
-3: foo = -3, bar = 255
-2: foo = -2, bar = 255
-1: foo = -1, bar = 255
0: foo = 0, bar = 0
1: foo = 1, bar = 1
2: foo = 2, bar = 2
3: foo = 3, bar = 3
4: foo = 4, bar = 4
.
.
.
252: foo = 252, bar = 252
253: foo = 253, bar = 253
254: foo = 254, bar = 254
255: foo = 255, bar = 255
256: foo = 256, bar = 255
257: foo = 257, bar = 255
258: foo = 258, bar = 255
259: foo = 259, bar = 255
Finally, com.sun.media.jai.util.ImageUtil.java does this to clamp a byte value
which is equivalent to what I was doing. I need to clamp both ends reliably.
I wonder if it can be done with shifts and masks? Maybe I've done the best
that can be done.
public static final byte clampByte(int in) {
return (in 0xFF ? (byte)0xFF : (in = 0 ? (byte)in : (byte)0));
}
Ken Warner wrote:
Never mind -- found it...
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19
At run time, shift operations are performed on the two's complement
integer representation of the value of the left operand.
The value of ns is n left-shifted s bit positions; this is equivalent
(even if overflow occurs) to multiplication by two to the power s.
The value of ns is n right-shifted s bit positions with
sign-extension. The resulting value is � n/2s⌋. For nonnegative values
of n, this is equivalent to truncating integer division, as computed by
the integer division operator /, by two to the power s.
Now if I could only understand this...
[EMAIL PROTECTED] wrote:
if(r 0) r = 0;
if(r 255) r = 255;
if(g 0) g = 0;
if(g 255) g = 255;
if(b 0) b = 0;
if(b 255) b = 255;
Clumsy and awkward. Is there a better way to clamp
the values?
Maybe with a mask or something?
If your better meant faster, you might like to take a look at this:
https://jai-core.dev.java.net/source/browse/jai-core/src/share/classes/com/sun/media/jai/opimage/AddOpImage.java?rev=1.1view=markup
under computeRectByte()
//
// The next two lines are a fast way to do
// an add with saturation on U8 elements.
// It eliminates the need to do clamping.
//
sum = (s1[s1PixelOffset]0xFF) +
(s2[s2PixelOffset]0xFF);
d[dPixelOffset] = (byte)sum23) 31) | sum)
0xFF);
HTH,
-James
[Message sent by forum member 'jxc' (jxc)]
http://forums.java.net/jive/thread.jspa?messageID=230881
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0?
...easier - schmeazier -- looks pretty good to me. Thanks... I needed a kick in the head... [EMAIL PROTECTED] wrote: In my code i usually use Math.min and Math.max. It does take more lines, but the intent is obvious and the code is readable. You can play with OR'ing three AND'ed expressions. Each AND expression handles a specific color channel, using the shifted value as the base and shifted mask. Something like r 16 255 16 (for red) g 8 255 8 (for green) b 255 (for blue) Then, the result would be 255 24 | (r 16 255 16) | (g 8 255 8) | (b 255) It is shorter but not necessarily easier to understand without comments. [Message sent by forum member 'kirillcool' (kirillcool)] http://forums.java.net/jive/thread.jspa?messageID=230872 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] What's a trick way to clamp a byte to 255 - 0?
That's obscure enough to be intriguing -- do you have a link to the rules Java works within on shifts? Because the ( 31) looks a little magical. I will also be searching the docs [EMAIL PROTECTED] wrote: if(r 0) r = 0; if(r 255) r = 255; if(g 0) g = 0; if(g 255) g = 255; if(b 0) b = 0; if(b 255) b = 255; Clumsy and awkward. Is there a better way to clamp the values? Maybe with a mask or something? If your better meant faster, you might like to take a look at this: https://jai-core.dev.java.net/source/browse/jai-core/src/share/classes/com/sun/media/jai/opimage/AddOpImage.java?rev=1.1view=markup under computeRectByte() // // The next two lines are a fast way to do // an add with saturation on U8 elements. // It eliminates the need to do clamping. // sum = (s1[s1PixelOffset]0xFF) + (s2[s2PixelOffset]0xFF); d[dPixelOffset] = (byte)sum23) 31) | sum) 0xFF); HTH, -James [Message sent by forum member 'jxc' (jxc)] http://forums.java.net/jive/thread.jspa?messageID=230881 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] My cylindrical panoram viewer is up for beta test...
The reason I'm telling you all is that I've gotten a lot of help here. http://pancyl.com/ This is my cylindrical panorama viewer website. Let me know what you think. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] problem in loading page in mozilla
Go to mozilla.org and look for the forums there. Based on my experience, it won't help much. There are a bunch of inconsistencies in the way mozilla has integrated Java with Firefox. And if you tell them about it, they just point the finger at SUN and Java. The sad truth is that IE generally supports the Java plugin better than FF. [EMAIL PROTECTED] wrote: when iam writing in java script windows.open with full screen as argument its not supporting in mozilla but we are getting the result in IE. pl help me...its very urgent thanks regards Lakshmi [Message sent by forum member 'lakshmimadhuri' (lakshmimadhuri)] http://forums.java.net/jive/thread.jspa?messageID=229141 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why isn't BILINEAR scaling smarter?
Exactly! Just look at some of the various Graphics API's that have succeeded and failed. OpenGL -- succeed -- simple, low level graphics that the programmer put together. I think, anyway I like it. GKS -- remember GKS? -- failed. High level display lists. Multi level and really complicated. How about Java3D? Anybody using that? VRML -- anybody using that? What succeeds? Java2D. ImageIO and JAI. Simple low level stuff that the programmer puts together. Anyway that's the way I see things. I have a feeling that everbody will have a different opinion IMHO it's correct that Java only provides low-level APIs, that is building blocks that should be put together in different ways for different needs. [EMAIL PROTECTED] wrote: No API can be made flexible and smart enough to handle all possible situations. That's why programmers still have jobs. I agree and this is especially true for image manipulation. There's no thing such a single way to do e.g. image resizing. For instance, the approach with multiple passes is good for dealing with images functional for the lf of a desktop application, while if we'd like to do something more quality-oriented something more complex is needed (refer to this post for an example http://archives.java.sun.com/cgi-bin/wa?A2=ind0311L=jai-interestP=R9579I=-3). IMHO it's correct that Java only provides low-level APIs, that is building blocks that should be put together in different ways for different needs. PS Sorry, this is some kind of self-promotion :-) but this is related to the topic: http://mistral.tidalwave.it/infoglueDeliverLive/ViewPage.action?siteNodeId=368 [Message sent by forum member 'fabriziogiudici' (fabriziogiudici)] http://forums.java.net/jive/thread.jspa?messageID=228317 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Why am I getting a null pointer exception when I try to get the drawGraphics from a BufferStrategy?
Environment: Java 1.5.0.12; Win2K SP4
Every once in a while, if I stop or restart the applet at just the wrong time
I see the following exception. Line marked Here is the last code executed
in my stuff. I check to see if the BufferStrategy is null before trying to
get a new drawGraphics. It never says it's null.
It's annoying. I didn't begin to get these errors until I recoded to use
the canonical render loop for BufferStrategy.
java.lang.NullPointerException
at sun.java2d.SunGraphics2D.init(SunGraphics2D.java:213)
at
sun.awt.image.SunVolatileImage.createGraphics(SunVolatileImage.java:174)
at java.awt.image.VolatileImage.getGraphics(VolatileImage.java:224)
at
java.awt.Component$BltBufferStrategy.getDrawGraphics(Component.java:3563)
Here at pancyl.PanCylCanvas.newPixels(PanCylCanvas.java:243)
at pancyl.PanCylProjector.interpolateBC(PanCylProjector.java:749)
at
pancyl.PanCylProjector.setImageParametersAndPixels(PanCylProjector.java:316)
at pancyl.PanCylImageFetch.run(PanCylImageFetch.java:418)
at java.lang.Thread.run(Thread.java:595)
private void checkBufferStrategy()
{
if(bs == null)
{
System.err.println(BUFFER STRATEGY NULL...);
this.createBufferStrategy(2);
bs = this.getBufferStrategy();
}
}
private boolean DRAWATT = false;
public void newPixels()
{
//System.err.println(newPixels()...);
try
{
checkBufferStrategy();
do {
do {
Exception here - bg = (Graphics2D)bs.getDrawGraphics(); //this is line
243
//System.err.println(Get BufferGraphics...);
mis.newPixels(pixels, cm, 0, thisW);
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
if(DRAWATT)
drawAttribution();
bg.dispose();
//System.err.println(Dispose BufferGraphics...);
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());
}
catch (Exception ie)
{
ie.printStackTrace();
}
this.requestFocusInWindow();
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why isn't BILINEAR scaling smarter?
Bilinear interpolation uses a very small 4 pixel neighborhood to interpolate. My experience is that it works pretty good at upscaling -- maybe not so good at downscaling. Other interpolation methods work better at down scaling because they use a larger neighborhood. Bicubic; Lanczos etc. use a 16 pixel neighborhood and they do better at downscaling because they take a weighted average over a larger neighborhood. Automatically forcing multiple interpolations might not be the best thing to do on all images. Like for example, what if the dimensions of the image are both prime numbers. Or what if the image is really wide and not very high -- like a 360 degree panorama? How do you automatically apply a multi-step downscaling interpolation? No API can be made flexible and smart enough to handle all possible situations. That's why programmers still have jobs. Jim Graham wrote: [I sent this out a few days ago, but replied to the wrong address so I don't believe it went through - sending again...jim] The Bilinear filtering algorithm is a well known algorithm that has a very specific definition which we follow. If we automatically applied multiple steps based on the scaling factor then we would violate that definition and have to call it something else. On a more practical note, if someone has determined that the caveats of the bilinear algorithm are sufficient for their needs and we did perform multiple steps instead of one step then we would reduce performance which that particular developer might not appreciate. On another practical note, hardware accelerators do not perform multi-step scaling so we wouldn't be able to fire the request off to the video card and get hardware accelerated scaling (nearly free) if we instituted such a policy behind the scenes. If we did provide that mechanism automatically then it would have to be under a different name so that the developer could buy into the specific tradeoffs that it provides (better quality for 2x downscaling at the expense of about 7x performance). In the meantime, we publish blogs like the one you point to in order to educate our programmers about the definitions of the graphical terms and processes that our APIs allow them to access and how to use those well defined industry standard mechanisms to achieve their needs... ...jim [EMAIL PROTECTED] wrote: There is an article that mentions that one can improve the look of downscaling using BILINEAR by downscaling multiple times (each time by half): http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html The paragraph in question reads: To combat this issue, you can use a multi-step approach when downscaling by more than two times; this helps prevent the information loss issue and produces a much higher quality result that is visually quite close to that produced by Image.SCALE_AREA_AVERAGING My question is, why doesn't Java do this automatically under the hood? If I request BILINEAR or BICUBIC downscaling for a factor greater than two, why doesn't Java either do multistep scaling on my behalf or why doesn't the Java2D team add a new hint (to maintain backwards compatibility) which will tell Java2D to apply these filters using the multi-step method? I would much rather have this supported by the JDK than having people reinvent the wheel over and over. Thank you, Gili [Message sent by forum member 'cowwoc' (cowwoc)] http://forums.java.net/jive/thread.jspa?messageID=227363 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] OutOfMemoryError
Having just beat my head against a virtual brick wall for the last few days, I think I can help. Take a look at: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html In particular, note these arguments about 3/4 of the way down the page. -Xmsn Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples: -Xms6291456 -Xms6144k -Xms6m -Xmxn Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples: -Xmx83886080 -Xmx81920k -Xmx80m -Xms256M will set the initial swap space to 256 meg. -Xmx512M will set the maximum memory size to 512 meg. Use numbers appropriate for your computer. How you set the JVM arguments will depend on how you have your enviroment configured. I can't help you there. Also, try starting a separate thread to do your data analysis. You are running your data analysis in the AWT event thread. Best to just start a separate thread in your actionedPerformed handler and let go of the AWT event thread. Ken [EMAIL PROTECTED] wrote: Hi, I'm reading the integer data that is present in a .txt file and upon reading it I'm doing some compution. My program is working well and gud for small amount of data in the file, but when i'm trying to read large of amount of data that is present in the file I'm getting the below mentioned error. Exception in thread AWT-EventQueue-0 java.lang.OutOfMemoryError: Java heap spa ce at DataAnalysis.kohonen(DataAnalysis.java:472) at DataAnalysis.readfile(DataAnalysis.java:376) at DataAnalysis$submit.actionPerformed(DataAnalysis.java:215) at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.setPressed(Unknown Source) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Sour ce) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) The thing that I couldn't able to get is when I'm checking at the lines 472; 376; 215 in my code, those lines are blank lines which dont have any code. I couldn't able to know like what went wrong and where i went wrong. [Message sent by forum member 'sarath44' (sarath44)] http://forums.java.net/jive/thread.jspa?messageID=227518 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Exception in thread Image Fetcher 0 java.lang.OutOfMemoryError: Java heap space
Hi Ernst, Like most things Java, there are two viewpoints. I often hear that OOME is the last gasp of the JVM and that all attempts at recovery are futile -- sort of like being Boorg'ed. I don't believe that. It's an urban myth... In fact, I have a small applet that exhausts all memory and lives to tell the tale. http://pancyl.com/memoryhelp.htm What I think is that the guys who developed the memory allocation scheme for Java were smart enough to check to see if there was enough memory for the next allocation *BEFORE* they allocated it. My reasoning is that even though the next memory allocation may indeed require more than all available memory, before that last chunk is allocated, there is still enough to recover by dumping some objects (o = null;) and/or System.gc(). That's what my little applet does. It waits for the OOME to be thrown and then dumps what it has allocated and runs System.gc(). The problem I described is that ImageFetcher just suspends and doesn't signal the OOME so that I can take steps to recover. Ken Ernst de Haan wrote: Ken, Question is whether OOMEs can be handled gracefully at all. I'm not an expert in this field, but it may be that the JVM enters an error state as soon as this error is triggerred. Note that the JVM self may be unable to get sufficient resources for its basic operations. But then again, I'm not an expert. But I have witnessed heated discussions on this topic, a few years ago. So my suggestion is to first do some research to confirm OOMEs can in theory be handled gracefully. Cheers, Ernst === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Why isn't BILINEAR scaling smarter?
Couldn't you do this in a loop yourself and control the final interpolation just the way you want it? What if the image isn't divisible by two in one of it's dimensions? I think that it's better to leave the use of interpolation in the hands of the programer. [EMAIL PROTECTED] wrote: There is an article that mentions that one can improve the look of downscaling using BILINEAR by downscaling multiple times (each time by half): http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html The paragraph in question reads: To combat this issue, you can use a multi-step approach when downscaling by more than two times; this helps prevent the information loss issue and produces a much higher quality result that is visually quite close to that produced by Image.SCALE_AREA_AVERAGING My question is, why doesn't Java do this automatically under the hood? If I request BILINEAR or BICUBIC downscaling for a factor greater than two, why doesn't Java either do multistep scaling on my behalf or why doesn't the Java2D team add a new hint (to maintain backwards compatibility) which will tell Java2D to apply these filters using the multi-step method? I would much rather have this supported by the JDK than having people reinvent the wheel over and over. Thank you, Gili [Message sent by forum member 'cowwoc' (cowwoc)] http://forums.java.net/jive/thread.jspa?messageID=227363 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Exception in thread Image Fetcher 0 java.lang.OutOfMemoryError: Java heap space
Hi Jim, You raise some interesting points. The reason I used Toolkit was because of the simplicity of the code that I needed to write. I wrote an early version of my applet using ImageIO and BufferedImage. The code ended up being pretty complicated. Right now I use Toolkit; grab the pixels; flush the image and do all my image manipulations on the raw one dimensional byte array returned by the PixelGrabber. I have quite a lot of functionality wrapped up in a pretty small package. Less than 20k and it has it's own nearest neighbor; bilinear; and bicubic interpolators all built into the projection from cylindrical to rectilinear viewport. Take a look: http://pancyl.com/ And I'm so far along in my development cycle that recoding for ImageIO (which is really good stuf - no slight intended) that recoding for ImageIO would set me back a month or more. The thing is, PixelGrabber implements the ImageConsumer interface. And the doc's say an InterruptedException is supposed to be raised -- I quote the doc's in my previous message -- but it's not. That's the problem. If it was -- I'd be home free. The thread I do the PixelGrabbing from is just suspended. All other threads are still up and running. To be clear -- the image is downloaded; the image has been decoded by Toolkit; when I try to grab the pixels, my thread is suspended by ImageFetcher. The way I fetch the image from the server is I just download it as a byte array then give it to Toolkit to decode. Really simple code. It all works with reasonable speed considering the usual constraints on downloading a 1 meg file over the internet. Another handicap is that I don't have the source to class sun.awt.image.ImageFetcher extends java.lang.Thread It's one of those mystery classes. If I had source, a workaround might pop out at me. Do you have the source to sun.awt.image.ImageFetcher or know where I can get it??? Ken Jim Graham wrote: Hi Ken, QUESTION: does anyone have an idea of how to handle this situation? Shouldn't ImageFetcher.run() throw something? Like an OutOfMemoryError or something so that grabPixels() can throw an InterruptedException like the documentation says it will??? The ImageFetcher should capture any errors and pass on an ERROR condition to all ImageConsumers. Is that happening here? My suggestion would be to use ImageIO instead of the Toolkit image facility for a couple of reasons: - Getting pixels via PixelGrabber goes through some really indirect mechanisms that should be slower than ImageIO (YMMV as we haven't necessarily benchmarked your particular usage, but it would be a safe bet). - ImageIO does the image loading in your own thread so you can catch such errors and deal with them with a lot less fuss. - ImageIO will deliver you one single copy of the image - when you use PixelGrabber and Toolkit images then you run the risk of the Toolkit image storing the pixels itself and then also feeding them to your PixelGrabber which would double the amount of memory needed and the memory used for the Toolkit image is harder to control since it is managed by another mechanism (hint: Image.flush() should get rid of it, but be careful not to trigger it to reload the image data again in the future). To give you an idea - image.getWidth(canvas) is enough to trigger the Toolkit image to load and store its own version of the image. - Also, if the Toolkit image is loading its own version of the image in addition to the data it delivers to your PixelGrabber, that is even more of a performance loss. - (BTW, PixelGrabber can get the W/H itself and create an array for you if you use the PixelGrabber(image, 0, 0, -1, -1, forceRGB) constructor. That would avoid the second copy loaded for the Toolkit image problem...) Have you tried ImageIO? ...jim === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Question about recommended render loop for BufferStrategy...
Ken Warner wrote:
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics graphics = strategy.getDrawGraphics();
//render here
graphics.dispose();
} while (strategy.contentsRestored());
So I did that where I render:
do {
do {
bg = (Graphics2D)bs.getDrawGraphics();
mis.newPixels(pixels, cm, 0, thisW); //MemoryImageSource
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());
So I'm disposing of bg -- the BufferStrategy graphics after I render.
The question is --
how come I can still use the buffer graphics (bg)
at other times to draw stuff.
My applet draws onto the BufferStrategy (bs) in many other places at
various times. And it works after I have dispose()'ed of the
buffergraphics (bg) and the loop above is the only place I getDrawGraphics();
For example -- here's my paint() method -- no problem -- no drawGraphics.
public void paint(Graphics g)
{
//System.err.println(paint());
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
bs.show();
}
paint() should fail but it works just fine.
I don't understand how paint can drawImage if bg is disposed.
Ken
Dmitri Trembovetski wrote:
Ken Warner wrote:
Hi Dmitri,
I don't call repaint() from my code ever. I have ignoreRepaint() set for
the Canvas component. paint() is only called from the AWT eventloop on
expose and events like that -- do I understand that right?
The loop below is called from my own looping thread when I get some
newPixels for my MemoryImageSource. I have not seen any problems.
But I know that my applet is not accelerated on my machine. It only
has unaccelerated bitblt from the BufferStrategy. I can't test
real acceleration. My machine is too old.
What I'm trying to say -- clumsily -- is that I believe that only one
thread at a time could render to my buffer -- I think...
OK.. Then what's the question, again? I'm sorry, I'm just
not following.
Thanks,
Dmitri
Ken
Dmitri Trembovetski wrote:
Hi Ken,
first of all, rendering to the same graphics context from
multiple thread is not a good idea. Java2D does not
guarantee thread safety, and doing so could
lead to unpredictable results (and even crashes due
to bugs in our code). So, please don't do that.
As to your question why it works - you just got
lucky and the paint on EDT executed while another
thread was in between the getDrawGraphics() and dispose().
After the dispose() all rendering operations to a
graphics context become no-ops, so by definition you
would only see something rendered the paint event
happened to be while the graphics was still valid.
Thank you,
Dmitri
Java2D Team
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Question about recommended render loop for BufferStrategy...
I'll have one available by tomorrow am.
Thanks for your time.
Ken
Dmitri Trembovetski wrote:
If you can put together a complete test which shows
that you can render to a Graphics object after it's
been disposed (and stuff shows up in the destination),
that would be a bug.
If you can, please send the test over. Otherwise it
is hard to tell what could be wrong.
Thanks,
Dmitri
Ken Warner wrote:
Ken Warner wrote:
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics graphics = strategy.getDrawGraphics();
//render here
graphics.dispose();
} while (strategy.contentsRestored());
So I did that where I render:
do {
do {
bg = (Graphics2D)bs.getDrawGraphics();
mis.newPixels(pixels, cm, 0, thisW); //MemoryImageSource
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());
So I'm disposing of bg -- the BufferStrategy graphics after I render.
The question is --
how come I can still use the buffer graphics (bg)
at other times to draw stuff.
My applet draws onto the BufferStrategy (bs) in many other places at
various times. And it works after I have dispose()'ed of the
buffergraphics (bg) and the loop above is the only place I
getDrawGraphics();
For example -- here's my paint() method -- no problem -- no drawGraphics.
public void paint(Graphics g)
{
//System.err.println(paint());
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
bs.show();
}
paint() should fail but it works just fine.
I don't understand how paint can drawImage if bg is disposed.
Ken
Dmitri Trembovetski wrote:
Ken Warner wrote:
Hi Dmitri,
I don't call repaint() from my code ever. I have ignoreRepaint() set for
the Canvas component. paint() is only called from the AWT eventloop on
expose and events like that -- do I understand that right?
The loop below is called from my own looping thread when I get some
newPixels for my MemoryImageSource. I have not seen any problems.
But I know that my applet is not accelerated on my machine. It only
has unaccelerated bitblt from the BufferStrategy. I can't test
real acceleration. My machine is too old.
What I'm trying to say -- clumsily -- is that I believe that only one
thread at a time could render to my buffer -- I think...
OK.. Then what's the question, again? I'm sorry, I'm just
not following.
Thanks,
Dmitri
Ken
Dmitri Trembovetski wrote:
Hi Ken,
first of all, rendering to the same graphics context from
multiple thread is not a good idea. Java2D does not
guarantee thread safety, and doing so could
lead to unpredictable results (and even crashes due
to bugs in our code). So, please don't do that.
As to your question why it works - you just got
lucky and the paint on EDT executed while another
thread was in between the getDrawGraphics() and dispose().
After the dispose() all rendering operations to a
graphics context become no-ops, so by definition you
would only see something rendered the paint event
happened to be while the graphics was still valid.
Thank you,
Dmitri
Java2D Team
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-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 JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Question about recommended render loop for BufferStrategy...
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics graphics = strategy.getDrawGraphics();
//render here
graphics.dispose();
} while (strategy.contentsRestored());
So I did that where I render:
do {
do {
bg = (Graphics2D)bs.getDrawGraphics();
mis.newPixels(pixels, cm, 0, thisW);
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
drawAttribution();
bg.dispose();
} while (bs.contentsRestored());
bs.show();
} while (bs.contentsLost());
So I'm disposing of bg -- the BufferStrategy graphics after I render.
The question is -- how come I can still use the buffer graphics (bg)
at other times to draw stuff. My applet draws onto the BufferStrategy (bs)
in many other places at various times. And it works and all the while
I have dispose()'ed of the buffergraphics (bg) and the loop above is the only
place I getDrawGraphics();
For example -- here's my paint() method -- no problem -- no drawGraphics.
public void paint(Graphics g)
{
//System.err.println(paint());
bg.drawImage(canvasImage, 0, 0, thisW, thisH, this);
if(DRAWATT)
drawAttribution();
bs.show();
}
I don't understand that...
Ken
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Anyone have a good paper on implemetation details of Lanczoz interpolation?
I'm curious about the internal details of Lanczoz interpolation. I see a bunch of sinc()funtions but wonder how the usual implementations of Lanczoz resampling is actually done. Anyone have a link to a good paper? A practical paper? Most of the time, the theory gets too abstract for my level of concentration. Ken === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Making a BufferedImage managed
A quick note. I am working on a 360 panorama viewer. I'll describe briefly my architecture. I load images using my own file loader class from a separate thread spawned from the init() method of my applet. I download the image file as bytes in an ordinary file transfer. Once I have the image bytes I send them through the appropriate decoder to get an image. I then suck the pixels out of the image. Once I have the pixels, I flush() the image so all I have on the heap (I think they are on the heap) is the pixels in an integer array (in my case). Then in another class I call the projection class, I take whatever small piece of the pixel array I want to display -- apply whatever transform or interpolation I want directly on a small copy of my working set and then stuff those pixels into a MemoryImageSource that lives in my class that manages the drawing. I work on the pixels directly in plain Java. Yes I have to write my own implementations of my interpolators and translators and scalers or overlays or whatever, but that's where the fun and efficiency comes in. My drawing class has a BufferStrategy. After I newPixels() into the MemoryImageSource, I use the BufferStrategy graphics to draw the MemoryImageSource and then just show(). If I want to show portions of a different image, I repeat the process. It's fairly fast and really simple. BufferStrategy does all the VolitileImage managment I need. And I have an eventHandler loop that wakes up every 5ms to handle mouse and keyboard events that controls the projection process -- pan,tilt,zoom,etc. I set flags and values from the AWT event thread in a normal way so the AWT event thread doesn't hang waiting for me to finish anything and my eventhandler just loops through reading those flags and values as directives. Simple, small and fast. Your milage may vary... Ken [EMAIL PROTECTED] wrote: Chris, i=0 -- copy mapImage (in sysmem) to dummyImage (in VRAM) i=1 -- a) copy mapImage (in sysmem) to cached texture version of mapImage (in VRAM) b) copy mapImage (texture in VRAM) to dummyImage (in VRAM) later -- copy mapImage (texture in VRAM) to your Swing backbuffer (in VRAM) Thanks for your insight. So I guess there is nothing I can do to speed up what you mention happens later. It seems there is no easy way to copy mapImage to the Swing backbuffer in anything other than the EDT (In fact I suggest the attempting to do so while more EDT's are on the way may really screw with Swing). I think I need to describe what I am trying to do, and why I can not think of a strategy better than spawning a Thread from paintComponent(). This thread does all of the work associated with loading an image from file (if it is not loaded) and then doing everything up to step 1b above. Think of scrolling and zooming in a 'GoogleEarth' like interface. Initially you have a base image, as you zoom in you move through layers other images, as you pan you see surrounding images. Scrolling and zooming occurs in response to mouse and key events, these in turn alter the model and a repaint of the state occurs. In each session hundreds, or even thousands, of 1000x1000 pixel images may be loaded. Keeping all of these in memory, just in case they are needed again, is not practical. Rather I ensure that only those that are needed are loaded then discarded when they are no longer needed. So this is smooth I currently determine which images should be displayed in paintComponent() then sp awn a thread to do the loading work(if not already spawned), actually only displaying the image after it is loaded. I guess I could move this further back, however it will still occur in the EDT. (Well maybe not, I could have a separate thread polling the zoom/pan state at some regular interval to determine which images should be loaded, or maybe use some loosely coupled propertyChangeEvent mechanism to manage the zoom/pane state and leverage of that - More to think about...) I did the single pixel thing - works fine on both pipelines on my machine. Regards, Alistair [Message sent by forum member 'alnrelly' (alnrelly)] http://forums.java.net/jive/thread.jspa?messageID=218476 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Making a BufferedImage managed
Thanks Javadesktop -- whomever you are... Good set of references. Some questions: I wrote an applet to display panoramic images. To display them properly, there is a necessary projection to make images look right. I won't go into the details of the projection but that projection is not in the Java2D toolkit. My question relates to how I implemented my drawing and updating. I use MemoryImageSource and BufferStrategy to draw an integer pixel array that I operate on directly for projection and interpolation. I get pretty good performance. I can completely redraw a 640x360 image in less than 70 ms with no flicker on a real old slow machine -- Win2K; 800 mhz processor; Java 5; old GeForce video card. But as always -- faster is better. So how does the use of MemoryImageSource and BufferStrategy differ from using VolatileImage? I'm guessing that there is a VolitileImage hiding in the basement somewhere in my implementation. Or should I consider rewriting using VolitileImages??? You shouldn't need to communicate with the SurfaceManager directly, since this is a sun private API. Lastly, all those nice runtime flags -- is there some way to set those flags from an applet or an application? Now that would be real useful. I think that we should not be protected from ourselves. Let us try these things out and let us deal with the consequences... Ken [EMAIL PROTECTED] wrote: Managed images only become managed after a certain number of render from operations, such as a call to drawImage(). The threshold is adjustable using the Sun specific flag: p -Dsun.java2d.accthreshold=x where x is the number of render operations before that image will be cached in VRAM. Setting this to zero should force all images to become accelerated on load. Note that any time you render to the image, it will become accelerated until you start rendering from it again. Further if you try to grab the DataBuffer directly, the image is no longer a candidate for acceleration since it can't tell when you're making changes to the image. p You shouldn't need to communicate with the SurfaceManager directly, since this is a sun private API. If you don't want to play with runtime properties, the obvious workaround is to ensure that the image is drawn to a dummy surface a few times before being used by the app. p a href=http://java.sun.com/j2se/1.5.0/docs/guide/2d/flags.html;This link/a details the runtime flags and Chet's blog on BufferedImages gives tonnes of stuff about acceleration: a href=http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a.html;Here/a and a href=http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a_1.html;here/a [Message sent by forum member 'fred34' (fred34)] http://forums.java.net/jive/thread.jspa?messageID=218010 === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] MemoryImageSource flickers when I update pixels with newPixels()...
Jim,
I figured out my problem. It had nothing to do with MemoryImageSource.
It was all my own dumb mistake. I've been almost entirely programming
in Swing for the last 5 years. Swing does all the buffering.
I started a little applet project in AWT just to get a small, light, fast
applet. It turns out that Component.update() either has changed or what
I was doing before never had a problem with update().
update() clears the drawing area -- in this case a Canvas -- to the background
color and then calls paint(). One must over ride update() to stop the
flickering and tearing. I just override update in MyCanvas to a stub.
update()
{
return;
}
Either I knew this once and forgot or it's changed since the last time
I made my own custom component from Canvas. It was all me.
And I pretty much am relying on BufferStrategy now so no offscreen drawing
what so ever. It works flawlessly now.
Thanks for responding
Ken
Jim Graham wrote:
When you set the animated attribute to true on a MIS it will never be
complete so drawImage will never return true.
The return value of drawImage should probably be ignored for 99.99%
of code - it doesn't tell you anything that you really need to know. All
it is telling you is if all of the image data has been completely loaded
from the source, but your ImageObserver will be notified when new data
is available so there isn't much you need to do with the return value
other than its informative (novelty?) value. In particular, if you
immediately reissue the drawImage call it will paint exactly the same
thing it painted the previous time until new data arrives (which isn't
likely to happen if you are wasting all of the CPU time repainting
something that hasn't changed yet).
With respect to the change in behavior in 1.4 vs. 1.5, I'm not sure what
might be causing that without a standalone test case. The only odd
thing I see is that you are double buffering things - dumping pixels
into canvasImage with newPixels and then immediately transferring them
to buffer with drawImage and later the pixels get dumped from buffer to
the screen with the drawImage in the paint method - why not just use the
drawImage to the screen directly?
...jim
Ken Warner wrote:
I'm haveing a strange problem -- I've used MemoryImageSource before with
great success. But now, doing the same thing I've done before in Java
1.4
I'm getting flickering on newPixels() in Java 1.5...
That is, when I send new pixels to my MemoryImageSource mis and
repaint() the image flickers badly. Didn't do this in 1.4.
The odd thing is that --
while((status = bg.drawImage(canvasImage,0,0,thisW, thisH,this)) ==
false);
never breaks because bg.drawImage never returns true. Do I have to
use a MediaTracker
or something???
Here's what I'm doing -- I've tried it using BufferStrategy and get
the same flicker
//this is an AWT Canvas
private Image canvasImage = null;
private Image buffer = null;
private Graphics2D bg = null;
private MemoryImageSource mis = null;
private ColorModel cm = null;
init()
{
thisW = this.getWidth();
thisH = this.getHeight();
mis = new MemoryImageSource(thisW,thisH,pixels,0,thisW);
mis.setAnimated(true);
mis.setFullBufferUpdates(true);
canvasImage = this.createImage(mis);
buffer = this.createImage(thisW, thisH);
bg = (Graphics2D)buffer.getGraphics();
}
public void paint(Graphics g)
{
g.drawImage(buffer,0,0,thisW, thisH,this);
}
public void newPixels(int [] newPixels)
{
mis.newPixels(newPixels, ColorModel.getRGBdefault(),0, thisW);
boolean status = false;
//while((status = bg.drawImage(canvasImage,0,0,thisW,
thisH,this)) == false);
bg.drawImage(canvasImage,0,0,thisW, thisH,this);
this.repaint();
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message signoff JAVA2D-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 JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] MemoryImageSource flickers when I update pixels with newPixels()...
I'm haveing a strange problem -- I've used MemoryImageSource before with
great success. But now, doing the same thing I've done before in Java 1.4
I'm getting flickering on newPixels() in Java 1.5...
That is, when I send new pixels to my MemoryImageSource mis and repaint() the
image flickers badly. Didn't do this in 1.4.
The odd thing is that --
while((status = bg.drawImage(canvasImage,0,0,thisW, thisH,this)) == false);
never breaks because bg.drawImage never returns true. Do I have to use a
MediaTracker
or something???
Here's what I'm doing -- I've tried it using BufferStrategy and get the same
flicker
//this is an AWT Canvas
private Image canvasImage = null;
private Image buffer = null;
private Graphics2D bg = null;
private MemoryImageSource mis = null;
private ColorModel cm = null;
init()
{
thisW = this.getWidth();
thisH = this.getHeight();
mis = new MemoryImageSource(thisW,thisH,pixels,0,thisW);
mis.setAnimated(true);
mis.setFullBufferUpdates(true);
canvasImage = this.createImage(mis);
buffer = this.createImage(thisW, thisH);
bg = (Graphics2D)buffer.getGraphics();
}
public void paint(Graphics g)
{
g.drawImage(buffer,0,0,thisW, thisH,this);
}
public void newPixels(int [] newPixels)
{
mis.newPixels(newPixels, ColorModel.getRGBdefault(),0, thisW);
boolean status = false;
//while((status = bg.drawImage(canvasImage,0,0,thisW, thisH,this)) ==
false);
bg.drawImage(canvasImage,0,0,thisW, thisH,this);
this.repaint();
}
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] Sub pixel sampling of Raster or DataBuffer in BufferedImage.
Hi, I'm writing an applet to show slightly distorted images. The applet it to apply small corrective mapping to straighten out the image for better viewing. The problem is that the corrections on a small image can be less than a pixel. It would be real handy if I could do sub-pixel averaging to interpolate an average pixel in between the four nearest neighbors. Pretty typical bi-linear interpolation. I can do this when I draw the image using RenderHints. But I want to do it as I access the source image. I lose too much information doing the interpolation at render time. What would be insanely great is if I could do a getPixel() using doubles or floats as the pixel address -- like getPixel(4.321, 5.749 Now that would be something! Am I being clear -- as mud? Does any one have a pointer to documentation or code that does sub-pixel sampling from either a Raster or DataBuffer in a BufferedImage? It would be a useful thing to review. Maybe I could get a better idea how to proceed with out losing the utility of BufferedImages. Ken Warner === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
