Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?
Perhaps that "OpaqueCopyAnyToIntArgb" loop is the reason any read of an image file into an TYPE_INT_RGB takes longer than reading into a bytearray image. BufferedImage bi = new BufferedImage(width,height,BufferedImage.TYPE_INT_RGB); irp.setDestination(bi); bi = reader.read(0,irp); The above is much slower than: BufferedImage bi = reader.read(0,null); which produces a BI with a DataBufferByte and this: BufferedImage bi = new BufferedImage(width,height,BufferedImage.TYPE_INT_ARGB); irp.setDestination(bi); bi = reader.read(0,irp); Doesn't work at all. It fails with -- java.lang.IllegalArgumentException: ImageReadParam num source & dest bands differ! at javax.imageio.ImageReader.checkReadParamBandSettings(ImageReader.java:2746) at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:907) at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:864) at pangnomic.PanGnomicImageFetch.makeBufferedImage(Unknown Source) at pangnomic.PanGnomicImageFetch.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) Jim Graham wrote: I grepped for "Blit" and "ByteBinary" and discovered that there are only convert (Blit(XX, SrcNoEa, YY)) loops for 1-bit to ARGB. The thing that surprised me, though, was that it took 4 times longer even despite the workarounds. I quickly ran a trace on copying a 1-bit image to INT_RGB and discovered that it ends up using a loop called "OpaqueCopyAnyToIntArgb" which is a Java loop that uses a couple of method calls per pixel. There are faster ways it could do this, even without creating a specific loop for this case, but it will take a bit of elbow grease as the logic in that part of the system is a little obscure... ...jim === 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?
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
This is what I mean. You <> give me crap for no reason what so ever. What a bunch of arrogant jerks. 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] Java OpenGL Acceleration Crashing
I think the "intel chip" referred to is the Intel graphics chip that is integrated on their motherboards. jav...@javadesktop.org wrote: Regarding: "Also note that no intel chip currently supports the OpenGL pipeline, it does not even support the D3D pipeline on windows because of driver bugs." Could you please provide the source for this statement? I'd like to read more about it. I have a GME965 on Fedora 10. Thanks! [Message sent by forum member 'smithsmithsmith' (smithsmithsmith)] http://forums.java.net/jive/thread.jspa?messageID=326254 === 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] Poor performance of Java2D
Nice job. Worked on my Win2K box with no native acceleration. Java 6u10. Got about 14-15 fps anti-alias -- 24-25 fps not. Noticed that when Gears is iconified it continues to run at full throttle taking 100% of my CPU. [EMAIL PROTECTED] wrote: *laughing* Just did the same thing a month ago: http://linuxhippy.blogspot.com/2008/11/jgears2-rendermark.html [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=318832 === 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
Like I said, "...oh well..." Might just be my old machine that is giving me inaccurate results from StrictMath. It's an old PIII. But I can't get back 0 or 1 from the sin() method when I need them to be 0 or 1. Also, what should be a straight integer multiply using real numbers for the integer value frequently returns a non integer result. I'll get back a number like (and this is a fabricated example for clarity not an actual calculation) 9. when I should get 10.0. Stuff like that and the trig() methods are really slow. I use a 7'th degree Legrange polynomial multiplication for an approximation of atan2() because it's faster than atan2(). That's not right... [EMAIL PROTECTED] wrote: Er... is StrictMath already FPU accelerated? If it is then, oh well... Its as far accalerated as the FPU produces acceptable results. For example on x86 the sin-command is used only in a special range where its known to be correct. The current Math package is really not very good. Especially or low level graphics stuff where 5 significant digits is the minimum accuracy that is useful. Almost can't believe that its so inaccurat, they do a great amount of work to ensure that as far as I know. After all, using straight FPU commands, accuracy won't be any better, at least on x86. lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=301778 === 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] Drawing to an off screen buffer
You can render in a different thread. I do in my viewers and they remain responsive. http://pancyl.com/LakeMary_1.htm [EMAIL PROTECTED] wrote: Thanks for all the hints. The frame rate I'm getting using invokeLater is very slow (~5 seconds per frame). And, the event dispatch thread gets clogged with lots of rendering tasks and becomes unresponsive. So, that's no good. My rendering is happening in response to user actions - scrolling, zooming, and mouse selections. My goal for the UI to remain responsive even if rendering takes several seconds. [Message sent by forum member 'cbare' (cbare)] http://forums.java.net/jive/thread.jspa?messageID=301639 === 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
My panorama viewers use a lot of the Math methods.
They are really slow and not all that precise.
http://pancyl.com/SittingRoom.htm
The trig functions are inaccurate near a multiple of
PI and zero. So much so that I have to check against
an Epsilon value and if the absolute returned value is
less than Epsilon then I manually set the value I need.
I also had to develop -- with some help -- an approximation
calculation for atan2() and I use a lookup table for asin().
I've found that lookup tables are not all that great near
a multiple of PI especially if you are trying to use a look
up table for tan/atan. They change very fast near their
asymptote. I use lookup tables "in the middle" but revert
to the real method near the poles with an Epsilon check.
I've wanted to gripe about the slowness and inaccuracy of
the Math package but who do I talk to?
[EMAIL PROTECTED] wrote:
Is there an alternate, faster way to do the maths?
The problem here is Math.round and Math.atan2, the Math class is optimized for
high precission but often sacrifices speed.
Your original version took 205ms on my C2D, replacing atan2 with this unprecise
version and removing the round braught it down to 35ms.
Be sure to use the server-runtime if possible, it gave me a solid 40% speed
boost :)
[code]
private final double aTan2(double y, double x) {
double coeff_1 = Math.PI / 4d;
double coeff_2 = 3d * coeff_1;
double abs_y = Math.abs(y);
double angle;
if (x >= 0d) {
double r = (x - abs_y) / (x + abs_y);
angle = coeff_1 - coeff_1 * r;
} else {
double r = (x + abs_y) / (abs_y - x);
angle = coeff_2 - coeff_1 * r;
}
return y < 0d ? -angle : angle;
}
[/code]
However that method seems to be very unprecise, a slightly better looking
result can be archived using this lookup-table based implementation, however
its slower (45ms):
[code]
package waterfall;
public class TableMath
{
private static final int TABLE_SIZE = 1;
static double[] atanTable = initAtanTable();
private static double[] initAtanTable()
{
double[] table = new double[TABLE_SIZE];
for(int i=0; i < TABLE_SIZE; i++)
{
table[i] = Math.atan(((double)i) / TABLE_SIZE);
}
return table;
}
private static double atan_1(int y,int x)
{
int index;
int vorz;
double erg = 0;
vorz = 1;
if (((x < 0) && (y < 0)) || ((x > 0) && (y > 0))) {vorz = 0;}
else x = -x;
/*atan of y/x */
index =(int) (((y*(TABLE_SIZE-1)*10)/x+5)/10); //+5 for rounding
erg = atanTable[index];
if (vorz == 0 ) return erg;
else return -erg;
}
public static double atan2(int y, int x) {
double result;
if(Math.abs(x) > Math.abs(y))
result = atan_1(y,x);
else
{
result = atan_1(x,y);
if(result < 0)
result = -Math.PI/2 - result;
else
result = Math.PI/2 - result;
}
if (x < 0)
if(y < 0)
result = result - Math.PI;
else
result = result + Math.PI;
return result;
}
}
[/code]
I don't know if any of those two implementations fit your needs, but they are
definitily faster ;)
Another possible optimization would be multi-threading, so each thread could do
a part of the total work - should be perfectly paralizeable. I am not sure if
unsynchronized write-access is valid (if no one is reading), but I guess it is.
That would bring the fastest version down to 20ms on my machine :)
lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]
http://forums.java.net/jive/thread.jspa?messageID=301636
===
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] 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
lg -- this is exactly what I've been trying to tell the Java2D guys for a couple of years now. They just tell me that I'm too stupid to understand the real value of BufferedImages. My view of the "downside" is that's where all the fun programming is. [EMAIL PROTECTED] wrote: Well, this seems really hard to optimize ... tons of very small primitives. The only advice I can give you is to grab the Raster of a INT_RGB buffered image: byte[] data=((DataBufferByte)tex.getRaster().getDataBuffer()).getData() (in your case its an int[] of course), and write code that does the drawing on the pixel-array itself. It should be really fast to colour those few pixels if you don't have to walk through a general framework, but instead do exactly what you need and that optimized. The downside of course is quite a lot of hand-written low-level code. lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=301094 === 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")
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
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")
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.
Re: [JAVA2D] Copying a portion of an Image?
uhhh Maybe you meant: BufferedImage snap = new BufferedImage(subw, subh, TYPE_INT_RGB); >>> Graphics2D g2d = snap.createGraphics(); Jim Graham wrote: Yes, if you want alpha you should pass in TYPE_INT_ARGB. Note that the default compositing mode of the freshly retrieved graphics object is SRC_OVER. The code sample still works fine since the newly constructed image is all 0's (transparent pixels) so copying your source image "over" the fully transparent image works just fine. But, if you try to reuse the image and copy a different section of the source image into it at a later stage then you might want to do the image copy using "g2d.setComposite(AlphaComposite.SRC)"... ...jim [EMAIL PROTECTED] wrote: // assuming: Image src; int subx, suby, subw, subh; // then execute: BufferedImage snap = new BufferedImage(subw, subh, TYPE_INT_RGB); Graphics2D g2d = snap.createImage(); g2d.drawImage(src, -subx, -suby, null); g2d.dispose(); // snap is now a snapshot of subx,y,w,h of src OK; thanks. If you didn't want a snapshot, I can outline other ways, but I'm guessing that this is probably what you wanted...? Yep. What allowed you to know that TYPE_INT_RGB was the correct parameter to pass in the BufferedImage constructor? If it helps, I know that the source image often has an alpha value set. Would I use TYPE_INT_RGBA in this case? Thanks again for helping this newbie out. Best, Laird [Message sent by forum member 'ljnelson' (ljnelson)] http://forums.java.net/jive/thread.jspa?messageID=295232 === 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] 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
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
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
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
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".
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".
[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".
Re: [JAVA2D] What is the proper way to compare drawing a BufferedImage and drawing an Image with BufferStrategy?
Thanks but that's really old stuff. And I don't think much of what is promised has happened. If you look at my applet, BufferedImage's draw slower than plain old Image's. BufferStrategy is a fairly good interface for VolatileImage's with some glitches showing up on full speed rendering loops. Seems to me that a lot more could be done now. Graphics cards are available with lots'o'vram these days. Thanks to the gamers. I just don't see BufferedImages as a real perfomance gainer [EMAIL PROTECTED] wrote: Don't know if you know Chet Haase's Blog entry about buffered images: http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a_1.html lg Clemens [Message sent by forum member 'linuxhippy' (linuxhippy)] http://forums.java.net/jive/thread.jspa?messageID=285580 === 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
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
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".
[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
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] Wouldn't it be great if all the RasterOp operations would work on plain ol' int and byte arrays?
That would be a really useful tool set if you could apply the operations encapsulated by the classes that implement the RasterOp Interface to byte and int arrays. I'm assuming that those ops are done somewhere in native code -- maybe even by the video card as accelerated operations. Having a tool set of those ops would make a lot of simple image manipulation operations on int and byte arrays -- that stupid, stubborn people (like myself) insist on writing -- go a lot faster. But I already know the answer -- "...use BufferedImages..." which is a perfectly fine answer if you want to use BufferedImages. But there is a big hole in the imaging API. And that is the lack of low level operations on arrays in J2SE. But then, I'm just stupid and stubborn. === 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".
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...
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 Buffe
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...
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".
[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)
//{
//if(PanTileApplet.DEBUG)Syst
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".
[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] 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?
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".
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".
[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
Yes, the various Java image classes accept all the drawing methods. In fact, you'll probably get a speed up in performance if you draw to offscreen buffers and then just draw the image once into the JPanel. Look in the various foums for info on double buffering. It's not so daunting as it sounds. Olsen Chris wrote: Ken -- Thank you very much for your lightning response! If I understand what you are saying, that is a terrific solution. So, then (to check my understanding), I can use what I think of as the Graphics2D statements (e.g. drawstring, fillRect, etc) and draw to an image? -- Chris Chris Olsen H.S. Math / Assessment Facilitator Educational Service Center 346 2nd Ave. SW Cedar Rapids, IA 52404-2099 -Original Message----- From: Ken Warner [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 10:22 AM To: Olsen Chris Cc: [EMAIL PROTECTED] Subject: 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] 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.
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] Question about fullscreen exclusive mode in applet in browser...
What I would suggest is putting a small 16x16 Java icon
in the upper left corner of the full screen window. That's
the conventional place for identification via icons. And
perhaps clicking on the icon could escape fullscreen
exclusive mode.
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.
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.
Also, there should be a choice of top or bottom
or invisible. If invisible, then show the icon in the upper
left corner.
Dmitri Trembovetski wrote:
The Applet bar is there for security reasons, obviously,
so we can't just remove it.
Now there are probably better ways to inform the
user that the window they're using is sandboxed,
and I believe there's some kind of project
to improve the UI of the security warning.
So, yes, this is not a 2D issue, but
security+awt+deployment.
Thanks,
Dmitri
Ken Warner wrote:
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".
===
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".
[JAVA2D] Question about fullscreen exclusive mode in applet in browser...
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".
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] 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".
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] 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] 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".
[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] 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
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".
[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
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".
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] 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?
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?
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?
[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 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] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA
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. 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".
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".
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] 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".
[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".
[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".
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] Please try the new Direct3D 9-based Java2D pipeline in 6uN EA
Hi Dmitri, I'm really excited to hear about this. The boost in performance will be a real advantage for Java in the Java vs. Flash war that is going on now. But I am running into a related problem. In the process of beta testing my panorama viewer, I'm encountered a lot of problems with MemoryErrors on client machines. The problem is easily remedied by setting the VM arguments. But at the same time, those same people exhibit a reluctance to simply open the Java Control Panel and set the VM arguments. I even have a whole system set up where by my viewer pops up an HTML page that explains that there has been a memory error and a link to an HTML page that explains how to easily fix it. Yet people still complain and point out that Flash doesn't have these problems. Now Flash 9 has supports a panorama viewer but the image quality is terrible. Java can render an image much more nicely and clearly. Yet, Java is still seen as deficient just because the default JVM memory parameters are too small and people are reluctant to take the 30 seconds it takes to set the memory parameters to a higher value. Is there any thought at SUN to set the default memory parameters for the JVM to a larger value? This goes back to an earlier discussion I had with you about the possibility of being able to set the JVM arguments to programmatically from an applet. Here is the memory help page I have available to the users that users seem to want to avoid. http://pancyl.com/memoryhelp.htm Ken Dmitri Trembovetski wrote: Hello, Sun had released an Early Access of 6uN (formerly known as the Consumer Release). You can get build b04 here: http://download.java.net/jdk6/ This build contains the new Direct3D 9-based Java2D pipeline, which is enabled by default on Windows platform. It is very similar to the OpenGL pipeline (in fact they share a lot of code), and is based on the Single Thread Rendering model developed for the OpenGL pipeline: http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html The D3D pipeline accelerates pretty much the same set of operations as the OGL one: http://weblogs.java.net/blog/campbell/archive/2004/11/behind_the_grap.html So, this is a call to action: Please try your applications with this new pipeline and let us know if you find any issues. We really want to make this pipeline rock-solid as it needs to be if it is to be left enabled by default. Time is short, so the sooner you report issues the better chances are we'll have time to fix them. Please report both negative and positive findings so we can keep track of what's working and what's not (and on which HW). Take a look at this page for testing/troubleshooting guidelines: https://jdk6.dev.java.net/testD3D.html (please make sure to include the output of J2D_TRACE_LEVEL=4 output with your postings) There are some known problems in full-screen mode, multi-screen, and on some chipsets (namely, Intel 645G). These are being worked on and hopefully will be addressed by the release time. Another thing to be aware of - this pipeline does not accelerate Xor rendering mode. It will be really, really slow. Sorry about that. Thanks, 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".
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 c<<23 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) & ~(c>>31))&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
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)p0&0x00FF) >> 16)*A0) + (((p1&0x00FF) >> 16)*A1) + (((p2&0x00FF) >> 16)*A2) + (((p3&0x00FF) >> 16)*A3)); g3 = (int)p0&0xFF00) >> 8)*A0) + (((p1&0xFF00) >> 8)*A1) + (((p2&0xFF00) >> 8)*A2) + (((p3&0xFF00) >> 8)*A3)); b3 = (int)p0&0x00FF))*A0) + (((p1&0x00FF))*A1) + (((p2&0x00FF))*A2) + (((p3&0x00FF))*A3)); r3 = r3 << 23) >> 31) | r3) & ~(r3>>31))&0xFF; g3 = g3 << 23) >> 31) | g3) & ~(g3>>31))&0xFF; b3 = b3 << 23) >> 31) | b3) & ~(b3>>31))&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
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
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 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)sum<<23) >> 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) & ~(foo>>31))&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) & ~(foo>>31));
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) & ~(foo>>31))&0xFF;
(1)- bar = foo << 23) >> 31) | foo) & ~(foo>>31))&0xFF;
(2)- bar = (byte)foo << 23) >> 31) | foo) & ~(foo>>31));
(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)Tim
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) & ~(foo>>31))&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) & ~(foo>>31))&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
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) & ~(foo>>31))&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)sum<<23) >> 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 n<>s 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.1&view=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)sum<<23) >> 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?
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)sum<<23) >> 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 n<>s 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.1&view=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)sum<<23) >> 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?
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 n<>s 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.1&view=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)sum<<23) >> 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".
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.1&view=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)sum<<23) >> 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".
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".
[JAVA2D] What's a trick way to clamp a byte to 255 - 0?
I'm doing the usual byte shift stuff to make a pixel. Part of my bi-cubic interpolation. Right now I clamp the value of a byte to be between 255 and 0 to prevent technicolor speculation. You know, those little annoying dots of out of place color. This is what I'm doing now. r = (int)(B0*(yReds[0]&0xff) + B1*(yReds[1]&0xff) + B2*(yReds[2]&0xff) + B3*(yReds[3]&0xff)); g = (int)(B0*(yGrns[0]&0xff) + B1*(yGrns[1]&0xff) + B2*(yGrns[2]&0xff) + B3*(yGrns[3]&0xff)); b = (int)(B0*(yBlus[0]&0xff) + B1*(yBlus[1]&0xff) + B2*(yBlus[2]&0xff) + B3*(yBlus[3]&0xff)); 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? === 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".
