Chet Haase's Blog

"Freebird!"

I'm a little afraid of posting this blog, thinking that it could resulting in either

• So many and varied requests that it will be difficult to address them all

• No responses at all. (If a blog falls in the forest and noone reads it, does it still make a sound?)

Nevertheless, I'll forge ahead. After all, the whole point in my blogs/articles is to talk about stuff that developers want or need to know more about.

So, in the words of the unforgettable sourthern rock band and Java desktop client developers Lynyrd Skynyrd:

What is it you want to hear?

In other words, what would you like to see articles on? I have a few ideas kicking around in my head that I'd like to cover, and people have suggested a few more. But if you have other ideas that you would like to have considered, please tell me in the feedback section below.

Here are a few topics that I would like to cover sometime soon, to give you a feel for where things are headed. If you have opinions on these, feel free to post those below as well:

• Managed Images: I've written about Managed Images in various forums so far (such as the BufferedImage (Part 1 and Part 2), VolatileImage (Part 1 and Part 2), and Image Strategies articles). But maybe managed images deserve their own dedicated article.
• Old vs New: I believe that some of the confusion and performance problems in Java graphics usage comes from the difference between the old Java graphics APIs (those written in the jdk 1.x days, e.g. ImageProducer, ImageConsumer, PixelGrabber) and the new ones (starting from jdk 1.2, e.g. BufferedImage). I would like to write an article (or maybe a series of articles) on the differences between these APIs and their implementations. Specifically, I would like to examine how developers would do things (such as image pixel manipulation) on the old graphics APIs and how they would do things using the newer APIs (hopefully better, faster, and more efficiently).
• Server-based graphics: This is also probably a series of articles. One thread is a discussion of how to do graphics operations (such as image creation and manipulation) in server apps (when you are not displaying to screen, but rather to/from images only). Another thread involves rich clients for server-based applications (such as Web Services); how can we make it easier to write clients that interact on the network and with servers? These are all pretty complex topics, so understanding and explaining the issues may take some time. But in this increasingly connected world, this seems like a useful topic in graphics development.
• ImageIO Utilities: While ImageIO simplified many things in image reading/writing and manipulation, it complicated some operations that are simpler in older APIs. For example, displaying an animated GIF is simple when loaded through some of the old 1.x APIs such as Toolkit.getImage(). But when using ImageIO, the developer needs to do much more work to display the images correctly. It's that whole "with great power comes great responsibility" thing; the power of the ImageIO APIs and the information that it exposes to the developer also (for now) necessitates more work to make some operations succeed. I would like to explore some of these issues to see if we can derive some simple frameworks or approaches that developers can reuse in their work to simplify their applications.
• Image Scaling: This is related to the "Old vs. New" topic above; some operations in our APIs are not obvious. Also, even when there are obvious methods in the API for accomplishing tasks, sometimes it is not clear how these methods work, or that the best ways of accomplishing the tasks are perhaps not related to the most obvious means. For example, Image.getScaledInstance() is not, in general, the best way to scale an image, either performance- or quality-wise. The Graphics.drawImage() methods are much better in general, but they are not necessarily obvious to developers new to the Graphics class. I would like to cover some of these areas and discuss the merits of the different approaches.
• Rendering Hints: Wouldn't it be nice to have the hints discussed in a single area where it is more clear (than in the current javadocs) what happens when various hints are enabled?
• Transform Tips & Tricks: There are always questions about how to go about transforming things correctly or most efficiently. We could explore some of these topics in an article or series of articles.
• Animation: Some of the *Image* articles have touched on this topic, but perhaps an article dedicated to animation would be helpful. This article could cover everything from performance tips to timer usage.
  Done! I've just posted an article entitled Timing is Everything on java.net. It doesn't cover animation as a whole, but has some information about timers and utility code I developed to add higher-level functionality to the existing Java timers.
  
• Intermediate Images: This topic comes out of something we've discussed in our JavaOne talks before: using images to cache complex rendering. This can be a huge win for animation or performance-sensitive graphics apps. Some sample code and implementation details here might help people take advantage of this high-performance approach to Java graphics development.
  Done! An article on Intermediate Images is now up on java.sun.com.
  

That's all I can think of for now, although I tend to add to my internal list of blog TODOs frequently.

Comments

• Animation Please!
  Hi Chet.

  Your blogs(/articles?) have been fantastic. They always get first priority in my reading pile.

  I've just started writing my first animated graphcis app (see http://image-tiles.dev.java.net) and, while it seems to be working okay, I worry about what I may have done wrong. I'd appreciate it if you'd write a brief technical blog on "Animation: how to do it!". What not to do would probably also be a good inclusion in such an article.

  A topic I'm hungry for information on is scheduling of the painting of frames.

  I'm using a self-written class that calculates the time to the next frame (1000*(1/frameRate)), then draws the current frame, and then sleeps until the time for the next frame. I could have used java.util.Timer.scheduleAtFixedRate(), but the source looked a little too heavyweight for what I was trying to do.

  My questions on this topic in particular are:

  - Is sleep() the write method to be using between frame draws? Is wait() better?

  - How can I improve the accuracy of my frame timing? currentTimeMillis() on windows appears to only have a granularity of 10ms, which means that frame rates that produce sleep times that aren't multiples of 10 (e.g. 40 FPS = 25 ms/frame) will have inaccurate paging.

  Thanks for asking what we want to hear!
  I look forward to seeing more of your revelaing and pragmatic brain-dumps soon.

  Graham.

  Posted by: grlea on August 23, 2004 at 08:03 PM

• ImageIO vs JAI
  Hello,

  what's about an imageIO vs JAI article. I am very interested over it.

  Regards,
  chris

  Posted by: lordy on August 24, 2004 at 12:32 AM

• All of the above and...
  I'd be interested in anything you could share on how the new graphics capabilities can be integrated with the Swing and AWT APIs to produce better, faster components.

  Posted by: bob_boothby on August 24, 2004 at 01:22 AM

• Fast Scaling
  Hi,

  So far your articles have been a great help for me getting through the image API jungle of Java. Thanks a lot!

  I'm currently working on an app that has its main performance bottleneck at the scaling of lots of images, thus fast scaling is my biggest concern. Therefore, I'd be most interested in the suggested topics 'Image Scaling' and 'Rendering Hints'. Additionally, I also would like to know if and when hardware acceleration will be available for scaling operations.

  Whatever topic will be covered next, I'm sure it will be worth reading.

  eb

  Posted by: el_barto on August 24, 2004 at 01:44 AM

• Animation Please!
  I second the animation vote!!

  Posted by: steevcoco on August 24, 2004 at 06:27 AM

• Animation Please!
  Another question:
  What's the best way to choose a frame rate?

  Is it:
  Component
  .getGraphics()
  .getDeviceConfiguration()
  .getDevice()
  .getDisplayMode()
  .getRefreshRate()
  ???

  Posted by: grlea on August 24, 2004 at 04:43 PM

• Image Rendering
  Hi,
  As I am working in image processing group of a multi-national company, so all of your articles will be of immense help to me.

  It would be better if you can provide and cover the following topics as well -
  1. Image rendering on screen - In java 1.1 we were able to display large images progressively by using imageUpdate, but that functionality does not seems to work with newer java versions. Moreover it would be of immense help if tips/suggessions can be provided on How to render the images on screen as soon as possible and progressively in java 1.2 and higher. Memory usage by images is also a major concern and bottleneck.

  2. Printing images- While priinting images in Java the printer job size is very large even for 1,4 and 8 bit images. This is because it gives 24 bit data to printer even if the image is 1 bit or even when the printer is black & white. Say ideally for a A4 sized B/W document it should have taken just 1 MB but it takes wooping 25mb. Is there any solution or workaround to it?

  Regards-
  Navjot
  

  Posted by: kashyap9_navjot on August 24, 2004 at 10:30 PM

• Fast Scaling
  Most image operations do require some kind of scaling to be done and that does seem to become a bottleneck... so it'll be great to hear more about how to blaze and scale.

  Posted by: ayush_gupta on August 25, 2004 at 12:19 AM

• Old vs New please..
  Old vs New would be very valuable - there is a *lot* of confusion over this if you look in the forums (I don't really understand it either)

  also a "RoadMap" style article would be good that spoke about which platforms would be able to pick up hardware acceleration and when, and to what extent (eg alpha effects)

  thanks,
  asjf

  Posted by: asjf on August 25, 2004 at 02:21 AM

• Layout managers
  Something that would help the new Java programmers would be a really good piece on the different Layout Managers. And no, not the usual JavaDoc stuff.

  Probably some quite thurough investigation must forego this though since the documentations is sparse at best.

  Which LM:s adhere to what properties would be good to have in a table format. For instance, min / preferred / max size are all handled differently by the layout managers, which is confusing since the documentation on this is almost non-existant.

  The power of LM:s is awsome, but that flexibility comes with a price; complexity (as usual). Complexity isn't a problem with good and up-to-date documentation though. That is currently missing or is hard to be found (a.k.a. old).

  Just my 2c

  Posted by: mgrev on August 25, 2004 at 11:00 PM

• No transparency
  Explain why java apps can't have transparency over native windowing.

  Posted by: jseltzer on August 26, 2004 at 08:19 PM

• Layout managers
  imho, there is already enough good documentation on the Layout Managers - is just that they cover the wrong area of possible layout behaviours

  i've found the JGoodies guy's FormLayout is much simpler to use for many things

  i've also heard that QT has simpler layout managers that provide a better base for constructing panels - perhaps a "Response to LayoutManager critics" article would be good?

  or even better some news that someone has sat down and sorted the whole area out :o)
  

  Posted by: asjf on August 27, 2004 at 06:45 AM

• No transparency
  This doesn't really seem like an article/blog idea; more of a question about our implementation.... But let's see if I can address it here.

  If I understand your question correctly, I think you're asking about support for translucent toplevel windows (correct?). We do support translucent components such as internal frames, but do not currently support translucent toplevel windows. So, for example, you cannot have a translucent Swing window such that you can see the non-Java desktop through that Window.

  The reasons we don't currently support this are basically resources (it's just one more thing to do...) as well as cross-platform native support for this type of capability. However, that doesn't mean we won't support it in the future; in fact people are looking into this now.

  So don't look for it in 5.0 (it ain't there), but do look forward to it in future releases.

  Posted by: chet on August 27, 2004 at 07:31 AM

• Layout managers
  Thanks for the layout feedback. I'm no layout expert so I probably won't be blogging on this anytime soon, however I've forwarded this feedback to the Right People here in case they can take this on.

  Layout can be difficult; anything we can do to either simplify layout management or explain it better would be a Good Thing...

  Posted by: chet on August 27, 2004 at 07:36 AM

• Animation Please!
  I'll write more about animation in a future article, but here's a quick response in the meantime.

  Choosing a frame rate should not be based on whatever the current frame rate is;it should be based on a combination of how often you want to update your app the the user (the minimum acceptable rate, from the user's point of view) and the maximum possible sustainable rate (how fast you can update things without hiccupping on complex frames).

  There is no inherent connection between the "refresh rate" of the current display mode and the rate at which your app will update the screen. That is, when you are running in windowed mode, any copies from the back buffer to the window (whether manually buffered or via BufferStrategy) will happen as quickly as possible, regardless of the physical refresh rate of your display. So connecting the refresh rate of the display to your app's frame rate makes no sense; you won't get around any tearing artifacts due to copying-while-refreshing by trying to match the rate.

  If you are fullscreen mode and use BufferStrategy, you may be able to use the FlipBufferStrategy, which _does_ sync itself to the refresh rate. But in this case, you can set the refresh rate as part of setDisplayMode(), so again you do not have to get the current display mode because you can set it to whatever you want (out of the possible rates; call getDisplayModes() to get an array of the possibilities).

  One other minor point on your method call above: you can get the GraphicsConfiguration directly from the Component: just call Component.getGraphicsConfiguration(). The rest of the method calls make sense, if you want the refresh rate. But again, there's really no need for you to get that rate in this situation.

  Posted by: chet on August 27, 2004 at 07:48 AM

• Rendering Hints & Transfomation
  That would be very nice.

  Posted by: tiom on August 30, 2004 at 11:56 PM

• Animation Please!
  Animation/timing is definitely on the list for an upcoming article. But in the meantime, check out the new System.nanoTime() call in jdk 5.0; way better resolution than System.currentTimeMillis().

  wait() could be fine, but it takes a bit more work to use it (you have to notify from other threads to wake up the waiting thread). sleep should work pretty well; just be sure to sleep for a small enough increment that you don't overshoot your target. But don't sleep so little that you spin in a tight loop; I'd call at least Thread.sleep(1) instead of sleep(0). Also, you can use yield to make sure you're ceding time to other threads.

  Posted by: chet on September 04, 2004 at 02:12 PM

• Immediate mode rendering with the OpenGL pipe
  Now that there is an OpenGL pipeline, tell me how I can gain access to it to make calls to the underlying OpenGL subsystem. You want me to do cool stuff? Don't block the pipeline :) Give me a way to render before the Java thread and a way to post process after Java renders.

  To me all rendering should be done in OpenGL for my applications - I now explicitly require it by setting the propertly in my main method as the software path is painfully slow.

  Posted by: gregorypierce on September 23, 2004 at 01:22 PM

• Immediate mode rendering with the OpenGL pipe
  This is more of a request for a feature from the library than an article about how to use the library...

  If I understand your request, it sounds like you're looking for a way to get access to, or share, the Swing back buffer. So we can render Swing into the buffer (using OpenGL, or whatever), and you can do your own (native? JOGL?) rendering in that same buffer. Is that correct?

  That's something we are looking into for future release, but which we do not currently provide. There are various tricky issues here, so we want to make sure the API for granting such access makes sense going forward before we go down that road.

  So don't look for an article on this anytime soon (since there's no such feature to talk about...)

  Posted by: chet on September 23, 2004 at 03:10 PM

• Animation Please! Finally got an initial article/project out there. Check out Timing is Everything and the project timingframework.dev.java.net for information and sample code on time-based programming in Java.

  Posted by: chet on February 15, 2005 at 04:29 PM

• ImageCreation from bytedata:For creating an image from an byte array i used imageio.read(new ByteArrayInputStream()) and some times toolkit.createImage(bytedata) with ImageObserver.In both cases i noticed that first time the time taking is 350 to 400 milliseconds.And then it reduces to 65 to 70 ms (for 640x480 , live streaming).

  Is there any methods or aps to decrease the time taken for reducing the image creation?

  
  

  Posted by: abhijithvr on March 03, 2005 at 08:59 PM

This work is licensed under a Creative Commons License.