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 --
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
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)]
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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,
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
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
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
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
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
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
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,
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
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]
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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?
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
. 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
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
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
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
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
[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
* 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
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
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
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
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
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
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
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
-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
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
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.
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
---
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
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
It was a localization problem. I was using class variables for all the
intermediate channel values. Switching to local variables -- method variables
-- I see the slight speed up I was expecting.
Example:
r3 = (int)p00x00FF) 16)*A0) + (((p10x00FF) 16)*A1) + (((p20x00FF)
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
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
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;
= 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
= + 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
));
}
Ken Warner wrote:
Never mind -- found it...
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19
At run time, shift operations are performed on the two's complement
integer representation of the value of the left operand.
The value of ns is n left-shifted s bit
...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
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 =
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
Go to mozilla.org and look for the forums there. Based on my experience, it
won't help much. There are a bunch of inconsistencies in the way mozilla has
integrated Java with Firefox. And if you tell them about it, they just point
the finger at SUN and Java.
The sad truth is that IE generally
Exactly! Just look at some of the various Graphics API's that have succeeded
and failed. OpenGL -- succeed -- simple, low level graphics that the programmer
put together. I think, anyway I like it.
GKS -- remember GKS? -- failed. High level display lists. Multi level and
really complicated.
Environment: Java 1.5.0.12; Win2K SP4
Every once in a while, if I stop or restart the applet at just the wrong time
I see the following exception. Line marked Here is the last code executed
in my stuff. I check to see if the BufferStrategy is null before trying to
get a new drawGraphics. It
Bilinear interpolation uses a very small 4 pixel neighborhood to interpolate.
My experience is that it works pretty good at upscaling -- maybe not so good
at downscaling. Other interpolation methods work better at down scaling because
they use a larger neighborhood. Bicubic; Lanczos etc. use a
Having just beat my head against a virtual brick wall for the last few days, I
think I can help.
Take a look at:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
In particular, note these arguments about 3/4 of the way down the page.
-Xmsn
Specify the initial size, in bytes,
Hi Ernst,
Like most things Java, there are two viewpoints. I often hear that OOME is the
last gasp of the JVM and that all attempts at recovery are futile -- sort of
like being Boorg'ed.
I don't believe that. It's an urban myth...
In fact, I have a small applet that exhausts all memory
Couldn't you do this in a loop yourself and control the final interpolation
just the way you want it?
What if the image isn't divisible by two in one of it's dimensions? I think
that it's better to leave
the use of interpolation in the hands of the programer.
[EMAIL PROTECTED] wrote:
There
Hi Jim,
You raise some interesting points. The reason I used Toolkit was because of
the simplicity of the code that I needed to write. I wrote an early version of
my applet using ImageIO and BufferedImage. The code ended up being pretty
complicated. Right now I use Toolkit; grab the
Ken Warner wrote:
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics graphics = strategy.getDrawGraphics();
//render here
graphics.dispose();
} while (strategy.contentsRestored
can, please send the test over. Otherwise it
is hard to tell what could be wrong.
Thanks,
Dmitri
Ken Warner wrote:
Ken Warner wrote:
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics
According to the documentation on:
http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html
One is supposed to
do {
Graphics graphics = strategy.getDrawGraphics();
//render here
graphics.dispose();
} while (strategy.contentsRestored());
So I did that where I
I'm curious about the internal details of Lanczoz interpolation. I see a bunch
of sinc()funtions but wonder how the usual implementations of Lanczoz
resampling is actually done.
Anyone have a link to a good paper? A practical paper? Most of the time, the
theory gets too abstract for my
A quick note.
I am working on a 360 panorama viewer. I'll describe briefly my architecture.
I load images using my own file loader class from a separate thread spawned
from the init() method of my applet. I download the image file as bytes in an
ordinary file transfer. Once I have the
Thanks Javadesktop -- whomever you are...
Good set of references.
Some questions:
I wrote an applet to display panoramic images. To display them properly, there
is a necessary projection to make images look right. I won't go into the
details of the projection but that projection is not in
buffer to
the screen with the drawImage in the paint method - why not just use the
drawImage to the screen directly?
...jim
Ken Warner wrote:
I'm haveing a strange problem -- I've used MemoryImageSource before with
great success. But now, doing the same thing I've done before in Java
I'm haveing a strange problem -- I've used MemoryImageSource before with
great success. But now, doing the same thing I've done before in Java 1.4
I'm getting flickering on newPixels() in Java 1.5...
That is, when I send new pixels to my MemoryImageSource mis and repaint() the
image flickers
or DataBuffer in a BufferedImage? It would be a useful thing
to review. Maybe I could get a better idea how to proceed with out losing the
utility
of BufferedImages.
Ken Warner
===
To unsubscribe, send email to [EMAIL PROTECTED
98 matches
Mail list logo
