![]() While this did indeed speed up my custom rendering, it made the rest of the application incredibly slow. ![]() It can be activated with the JVM parameter =true ( Oracle docs). ![]() While searching for a way to speed up the rendering, I noticed that, by default, Java does not use OpenGL. It also uses video memory, which is often a lot more scarce than system memory, so keep that in mind. VolatileImage is a bit trickier to use than BufferedImage, so have a look at a few examples before using it everywhere in your codebase. We can easily create each half of the buffer with the following code: This means we have to fumble the code back again and use a JPanel with a custom double buffer implementation. I found some hacks and JVM arguments that should suppress the clearing of the canvas, but nothing that looked very robust. While our buffer content will eventually be restored, for a few milliseconds the content is blank - hence the flickering. The canvas flickers violently every time the window size of our player changes.Ī quick debugging session and some guesswork lead to the conclusion that our canvas is cleared by the JVM, or even natively by the OS, when resizing. No biggie, we can simply use the AWT Canvas class instead.Īfter we’ve fumbled this into our code, we delightedly see that it works great - that is, until we try to resize the window. When looking at Oracle’s JavaDoc, it seems like the best way to do this is to use the createBufferedStrategy(2) method.Īfter a quick search, we see that JPanel, of course, does not support this. When our frame has finished rendering, we flip the buffer and display it. What we need is some kind of double buffering, where we can render each frame in a separate thread so it won’t block the EDT. Since our weather forecast is probably made up of different layers, we end up blocking the Event Dispatch Thread (EDT) almost all the time just with our drawing routine. On my machine, drawing a single fullscreen BufferedImage frame in a JPanel takes between 10ms and 150ms. The problem is that drawing in Swing is really, really slow. You can read the images into a BufferedImage with Java’s ImageIO library and then display that image in a JPanel (or one of the other components that can display an image).Īnd the good news is that this actually kind of works – if you don’t mind the huge latency you experience for every new frame. That doesn’t sound so hard, you hear yourself thinking. Now suppose you want to play this (very slow) video/animation with Java Swing. Not like one of those 60fps 4k movies, more like those choppy weather forecast animations on the weather app that came preinstalled with your phone and has approximately 3fps. ![]() So, suppose you’ve generated a few images which make a nice animation when shown in quick succession. TL DR: Don’t do it (unless you fancy surprises). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |