SDN Chat Sessions Transcripts Index
February 15, 2005
Guests: Chet Haase and Scott Violet
Moderator: Edward Ort (MDR-EdO)
This is a moderated forum.
MDR-EdO: Welcome to today's SDN chat "Getting High Performance from Your Desktop Client." Our guests today are Chet Haase and Scott Violet. Chet is a key member of the Java 2D engineering team, and often focuses on graphics performance-related topics. Scott is the architect for JFC/Swing. Chet and Scott are ready to answer your questions about desktop client performance. So let's start. Who has the first question?
scottd: Why are repaint freezes gray?
Scott Violet: This is a very timely question. When using AWT/Swing there are at least two threads: One that is responsible for receiving and processing native events, and the other thread for dispatching these events (the EDT). The native thread, when it receives an expose event, immediately fills in the background in gray and when the event is processed on the EDT we do the real painting. In this way if your application is busy there can be a noticeable delay between when the gray area is shown and when you actually paint. The good news is we're working on a fix such that each window will have a buffer associated with it, so that when we get an expose event we immediately copy from the back buffer and your application doesn't have to do anything. In this way you'll never get a gray rectangle, and even if your application is busy we can still restore the contents. We hope to finish this work soon, and when we do I'll post about it so that you can download an early build and kick the tires.
bskaarup: We spend quite a lot of time making sure that our customers running Windows are current with regard to display drivers, DirectX and so on. Our Swing application often fails to redraw correctly when removing and adding components (especially the PCs with an integrated Intel graphics chip). Do you have any recommendations as to what we can do to our applications to not to be so dependent on the drivers and DirectX and at the same time render fast?
Chet Haase: We work pretty hard at making sure that such artifacts do not occur; if you are seeing problems, then it's a bug that should be fixed. Intel chips, in particular, we have had severe problems with. Do you know that some of their chips can't even draw a line that's only a single pixel wide? When we discover such problems, we tend to work around the issues or just disable functionality when we cannot work around it. For example, we disable d3d usage on Trident because of some severe problems they have in their drivers. I'd say the best things to do would be to track the problems, submit bugs so we know about them, work around the issues with command-line flags when necessary. A good flag to try is-Dsun.java2d.d3d=trueto disable our use of d3d.
antonio: Swing is cool!! Good job guys!!!
Scott Violet: Thanks! And I don't even think you are a Sun employee ;-)
JavaGeek: Why hasn't theSwingWorker(or a similar mechanism) made it to the standard APIs? What is the recommended way to deal with process-intensive tasks?
Scott Violet: Excellent question. It turns out we're very close to finishing up a version ofSwingWorkerthat will be part of 1.6. This is the version that Igor, Brent, Bino and myself talked about at last year's Java One conference. This version ofSwingWorkeris generified and supports property change listeners. It's extremely handy. I'll also mention that AWT is looking at a way that you can pump events during a long running process. Other toolkits provide similar mechanisms and it turns out it's very handy.
jansan: Looking at the past, you have achieved quite some improvements on client performance. Where do you see most potential for future improvements? I would like to see translucent painting and text measuring improved.
Chet Haase: Our acceleration story started out pretty simple; speed up the things that Swing needs the most. This meant accelerating fills, lines, and buffer/image copies in 1.4. Now we're down to the next level of acceleration, where things like translucency and text (anti-aliased and non-anti-aliased) are pretty important. This is happening in the current 6.0 work; we are rewriting our entire Direct3D stack to be able to handle translucency (rendering and image copies), transforms, and glyph caching all automatically. This is on Windows. Meanwhile, our 5.0 release had all of this and more through our OpenGL rendering pipeline (disabled by default, enabled via-Dsun.java2d.opengl=true).
frankg: What tips can you give to help us reduce the amount of time that ugly gray rectangle remains on the screen? It makes Swing appear to be slow...
Scott Violet: We're going to take care of it for you in 1.6. If all goes well you'll never see it again!
frankg: What happened to JDNC and JDIC? They've lost some air time over the past year.
Scott Violet: Both projects are continuing on very strongly.JDNCis working toward another milestone in the next month or so that will include a login framework, and revised data model/binding API. I'm not as up to speed onJDIC.
MisterMcGuire: Is there a good way to directly take advantage of the Java 3D APIs for hardware acceleration from lightweight components? I'm looking at imbedding an interactive 3D scene within a document in a customJEditorPaneinside aJScrollPane. What hints would you have for squeezing out performance with an off-screenBuffer3D?
Chet Haase: Java3D and lightweights still don't get along too well (Java3D uses a hardware back buffer that essentially blows a hole right through the display and tends to not cooperate too well with Swing's lightweight components). However, I've seen applications that use both Swing and Java3D (orJOGL, or some native OpenGL implementation) to great effect, either by having side-by-side views that use the different technologies or by having different rendering modes they can move into/out of.
swankjesse: I have aJTablewith variable-height rows. SinceSizeSequencerequires O(N) to process inserts and removes, inserts and removes to myJTableare very slow. Is there any way to get theJTableto use an alternateSizeSequence? Would it be worthwhile to changeSizeSequenceto use a tree internally so that all operations are O(log N)?
Scott Violet: It's O(n) for the rows that have a different row height. Do all rows have varying row heights? It's tuned toward only a handful of rows having varying row height versus all. That said, it should be possible to tune it a bit more, please file an RFE on java.sun.com.
bskaarup: The problem with-Dsun.java2d.d3dis that according to the Web Start guide, it is not among the secure properties and therefore will be ignored.
Chet Haase: I'm not aware of this issue; as far as I understand it, we will honor this property inside of Java2D. Maybe Web Start is not passing the property through? I'll have to check with the deployment team on this one. Meanwhile, file the bugs you find so that we can fix them.
NetSQL: Why does it have to be in 1.6, why can't it be a jar that I can use in 1.5?
Scott Violet: I assume you're referring toSwingWorker. We're considering releasing an unbundled version ofSwingWorkerfor 1.5 but nothing has definitively been decided yet.
bjb: What are the best practices around the event handling for getting high performance (event handler,SwingWorkers, anonymous classes overhead)?
Scott Violet: Having a one-to-one mapping between source and action will certainly be the fastest. But in actuality even if this dispatching is 10x or possibly 100x slower, the overhead is so slight that I don't think it'll matter. By that I mean that the majority of the time will be spent in your code, not the dispatching so it's best not to spend too much time trying to find the optimal solution. On the footprint side it's much clearer. Class loading is not free from a time or memory standpoint, so it's better to consolidate as many listeners as you can into a single class. That said, don't contort your application around this, do what makes the most sense.
Chet Haase: Question about 2D flags: I don't know whether we've collected all of these in a central place. Many of our flags tend to be temporary, so it doesn't make sense to make them too standardized. But there are a few that are good to know about like (all of these are preceded by-Dsun.java2d.):d3d=[true|false],ddoffscreen=true|false,noddraw=true|false,opengl=true|false. There are a few more for Linux/Solaris for pixmap settings. Check out articles on our2D websiteand postings onjava.net,javadesktop.org, andjavagaming.org.
bskaarup: There are only 6 of the-Dproperties that can be passedwhen using Web Start.
Chet Haase: Okay - I'll take a look and talk to the deployment folks. I didn't realize there was a Web Start constraint here.
JavaGeek: Are there some metrics of how the performance has improved since Swing 1.0?
Chet Haase: We'll do comparisons occasionally, but it really depends on what you are running. Our general benchmark for Swing is called SwingMark and it's shown pretty steady improvement over the years, with big jumps during releases when we enabled hardware acceleration (like 1.4).
Guest: What is the impact of threads and synchronize in our application code?
Scott Violet: I'll answer this as it relates to Swing/AWT. If you only invoke methods on Swing/AWT components from the event dispatching thread, you won't run into any problems.
cjn: Are there any examples/tutorials available for implementing efficient customPaintorCompositeclasses? (One example is a radial gradient) The few examples I've found use native, slow code.
Chet Haase: I don't know of any in particular.Vincent Hardy's Java2D bookis quite good, I believe (although I don't know if it covers this area specifically or if it has performance issues). I've done a few articles on the web about performance, but not in this area (although I've seen gradient performance improve dramatically through theIntermediate Imagestechnique).
Rob: Resizing frames is one area where Swing applications tend to look different from other applications in that the resize does not apply until the user stops resizing the window. Native applications tend to adjust the content as the resize happens. Any thoughts on how to implement this in a performance-friendly way?
Scott Violet: The good news is that if you want live resize, it's as easy as invokingToolkit.getDefaultToolkit().setDynamicLayout(true). How responsive this is depends upon your application and the contents of the window being resized. I will say we are looking into making live resize the default in 1.6 and so will also look at ways we can tune all that happens when you resize a window.
NetSQL: I know this is OT but.... How do we address deployment issues (Java Web Start)? Can we have a chat session on that? JavaOne?
MDR-EdO: Perfect question -- the very nextSDN chat session, scheduled for March 1 -- is on Java Web Start.
Rob: Any chance of getting ahold of SwingMark?
Chet Haase: Not a chance, sorry - it's an internal-only benchmark that's not likely to ever make it outta here alive. However, I think it's more important for you to develop benchmarks that are representative of the types of things your applications do. That's the best way to know how well Swing works and improves for you; using someone else's benchmark only tells you how well things behave for the types of things they decided to test.
scottd: Is that version going to have any sort of thread pooling mechanisms in it?
Scott Violet: StillSwingWorkerrelated I assume. Yes, the new version makes extensive use of the concurrency package.
frankg: Considering "other" companies are integrating their desktop environments with web services (for better or worse), will we ever see a collection of high-level Swing components that are web services aware?
Scott Violet: Most definitely. JDNC has these components and continues to investigate how easily we can do this. I'll also say that key to this is tools integration, and we're working closely with the NetBeans folks to make sure JDNC works well there too.
Lordy: Hey. I'm working on a application that should open 1.000-10.000 thumbnail pics (120x100 px jpeg). IsImageIcon(String filename)the fastest option or is imageI/O or JAI faster? And is there a difference by memory of these three?
Chet Haase: I know there were performance issues with ourImageIOjpeg loader in 1.4 that made it slower than the old Toolkit loader (ImageIcon/Applet/Toolkit/etc.). I do not know whether those issues were fixed or not. Best way to find out: write a simple microbenchmark that times the different approaches and see what works best for you. I'd like to see everyone move toImageIOeventually, but we maybe have some bottlenecks to fix first in order to get there. Don't know about JAI performance off-hand.
NetSQL: re:SwingWorker: Is this different than what is in JDNC CVS?
Scott Violet: It must beSwingWorkerday;-) Most definitely. If you look at the slides for last year'sthreading talkyou'll get an idea of what the API looks like.
cjn: By intermediate images in a gradient context, I assume you mean rendering the gradient to a offscreenBufferedImage, and then using the image in aTexturePaintto fill an arbitrary shape? On this note, there doesn't seem to be a way to reuse the sameBufferedImagefor multiple textures, sinceTexturePaintmakes a copy of the data buffer. Is there something I've overlooked? I'd like to pre-allocate a single offscreen buffer to be used for all temporary work.
Chet Haase: I actually mean just rendering the gradient to an image and simply copying the image. This worked well for a linear gradient example; don't know if it would work in your case exactly. By copying the image (as opposed to using it as aTexturePaint), you are guaranteed reuse for whatever else wants to reuse that gradient.
markyland: Are there any plans to allow Swing applications to be compiled natively?
Scott Violet: The closest thing I can say we're looking into is persisting compiled code between runs of the JVM. For example, each time you run your application we end up compiling a lot of the same methods; if this were cached it could conceivably speed things up. Whether or not something like this makes it in depends upon the results we get.
wberg: Java 1.5 comes along with Synth. I've tested a new Synth look and noticed that startup time for Swing applications goes up. What can I do to avoid this behavior?
Scott Violet: I suspect the slow down comes from using the XML parser. Could you please submit a test case so that we can better evaluate this to make sure that is in fact what's happening?
Dan: Is there supposed to be a speedup of Java2D drawing in 1.5 on Linux compared to 1.4? And can we get your SwingMark program?
Chet Haase: We released our openGL rendering pipeline on Linux in 5.0, which has pretty huge performance wins, depending on what your application does. However, the gl renderer is not enabled by default (due to robustness and performance issues with various cards/drivers), so you'd have to enable it explicitly (sun.java2d.opengl=true) and try it out on your target platforms to make sure it worked well for you.
JavaGeek: How closely are you working with the projects on dev.java.net? Particularly the ones dealing with desktop libraries/applications. There seems to be a lot of interesting projects that could help extend Swing (like data-aware components, L&F, etc.)
Scott Violet: Hopefully I can remember them;) The ones I know we're actively working with areJDIC,JDNC,jgoodiesandwinlaf.
codecraig: Any opinions on the 3rd party threading frameworks such asFoxtrot?
Scott Violet: I've had this argument both with the Foxtrot guys and internally. My biggest concern is that this approach requires the toolkit to be reentrant. In most cases you'll never see a problem, but in certain cases (like painting) you WILL see problems. As I mentioned earlier we're looking at providing a similar API in 1.6 and it's likely we'll make the API throw an exception if you try to use it in a place we know there will be problems.
JavaGeek: What about backporting some of these improvements (even Swing as a whole) to old versions of the JRE? Many companies still do all of their development in 1.3. Swing started as a separate component, anyway.
Chet Haase: We end up backporting specific fixes, but not large architectural changes (such as the use of hardware acceleration). I understand your issue, but the reality is that if we backported this stuff we probably wouldn't have time to do any new development. And given the huge list of things people want us to be working on (such as even more acceleration/performance/functionality/quality), we just have to make the hard decision to focus mainly on new releases.
antonio: After resizing aJComponent, the whole component area is repainted. Is there a way topaint()the damaged portion of the component only?
Scott Violet: Currentlyresize(orreshape, orsetBounds, whichever you prefer) does a complete repaint, so there is no easy way to workaround this. An idea here is to have a method that developers can override indicating whether or not a resize needs to repaint all, or just the new area. This will be problematic for theRepaintManagerbecause it unions rectangles, but it's an area we want to investigate.
JavaGeek: I can't wait for the newSwingWorkerto come out. Hopefully before Java 6.
Scott Violet: Thanks for the feedback.
Rob: A tad OT: The default fonts used by the XP look and feel look pretty bad. Anything being done to improve that situation? Also, it would be nice if all of the text-related and list controls would use the same font. If you drop a textbox and a combo box on a frame and use the XP look and feel, the combo and textbox use different fonts and look bad. You guys have made great progress but I hope these issues will be addressed.
Chet Haase: We hear you. Native look & feel fidelity is a big thing for us in Mustang. This means making the widgets look closer to the platform widgets, but it also means fonts. There are a lot of different aspects to this, including behaving the desktop settings for anti-aliasing as well as rasterization quality. We're looking into all of it.
jansan: To measure i18n text correctly, the only way I know isTextlayout, which is powerful but very heavy (=slow). Do you know of a leaner and faster way to measure text that may include right-to-left characters, different baselines, a composed font, etc.?
Chet Haase:TextLayoutis probably the best way to go...
bskaarup: Speaking Synth - when will you give us a complete L&F that uses Synth?
Scott Violet: Another tricky question. Thankfully we're going to have someone start work on that in the next couple of months!
swankjesse: FYI: I've posted an issue regardingSizeSequenceperformance to the BugParade. It's under evaluation as issue 398743 if anyone is interested!
Scott Violet: Yes, I'm interested, I'll see what I can do to make it a bug for you.
NetSQL: With the new threadedSwingWorkerin 1.6... do all the Swing jcomponents now have to be thread safe?
nScott Violet: No.SwingWorkermakes it easy to offload work, work that doesn't touch Swing, onto a separate thread and then do some processing back on the EDT when you're done.
antonio: IsSynthLookAndFeel.load( serializable bean here )in the making to avoid XML parsing overhead?
Scott Violet: Invoking that method will certainly trigger loading the XML parser.
bgalbs: Can we expect the Windows OpenGL driver issues to be resolved in 6.0, or is the intention that Windows users continue with the DirectX drivers? Also, do you know if the Mac JRE team is using your OpenGL pipeline for Tiger?
Chet Haase: We're definitely working on the GL issues. I'd like to see GL enabled by default; we just have to find ways around some of the egregious problems we've seen on pretty common boards. I don't expect GL to become the default on Windows, however; the support for GL tends to be less important for some companies than DirectX. Get Quake to work and then y\they're done. Until/unless that's fixed, expect DirectX to be the default. But in the meantime, we're taking the great stuff developed for our GL rendering and porting it to our DX pipeline so that we can get the same performance benefits through that renderer. Apple does not use our GL bits; they tend to rewrite the platform on top of their graphics toolkit du jour.
herpgps: How much will performance be affected when using Synth? And when will you have a demo example, with doc?
Scott Violet: As far as the performance, that really depends upon the skin. It'll be image based and so thatMAYbe more expensive than something simple using drawing primitives. I say may because that really depends upon the machine and other factors. I will say that we did more tuning for 1.6 to make painting even faster. Continuing that Synth answer, by making faster I mean when using images. And the demo I earlier referred to will be available as soon as we finish it. There are a couple of articles on Synth available on the web now, do a google for Synth.
frankg: IntelliJ is a Swing application and they get some very fast live redraw performance. Any chance Swing can have
Chet Haase: Not sure where your question would have ended up (it got cut off in my window here), but I'll just take a wild guess at this. You can definitely get great performance from a Swing application. Some of it is built into Swing (acceleration for the back buffer was pretty huge), some of it is clever use of the APIs and the threading model. For example, if your application does lots of computations on the event thread, your GUI will suffer slow perceived performance. One thing to note is that we're working on a fix to the "gray rect" issue where simple expose events on a window are handled much faster. This will be done by having the Swing back buffer be persistent, so all we do is copy the bits to the screen if nothing's changed. This should speed up all applications (not just intelliJ).
codecraig: Any idea of adding a "dockable" framework into Swing?
Scott Violet: Definitely. We're seeing more and more applications request this. We're packed with stuff for 1.6 now though, so, this won't be done until at least 1.7. That may sound too far in the future, but we're trying for shorter release cycles:)
codecraig: As far as "dragging" components in aContainerare concerned, any suggestions on a smooth way of creating a "ghost" of theComponentto be dragged? Essentially show an outline (or better a semi-transparent) version of thatComponentto be dragged?
Scott Violet: Yep, that's what aGlassPaneis for. We wanted to makeTransferHandlerdo this for you (it has the API), we just ran out of time. We plan on doing a number of drag and drop fixes/improvements for 1.6, hopefully something like this can make it.
powerdroid: Do you see that hardware acceleration (either OGL or DX on Windows) will be enabled by default for 6.0?
Chet Haase: er: it is... DirectX has been enabled by default on Windows since 1.4. Same in 5.0, same in the upcoming 6.0. Meanwhile, we continue to make that acceleration more powerful, so what you get by default will be more substantial. GL is another story; until we have a good feeling for whether we have workarounds for all of the driver issues we've seen on GL platforms, we don't know whether/when we can enable it by default. I will say, however, that we've seen some great quality advances in our internal 6.0 work; we've changed the way that we handle GL rendering with respect to threading, and that has helped some of the bigger problems we've seen on various cards/drivers. So maybe someday GL will be on by default - wouldn't that be nice?
herpgps: How much will Synth look and feel reduce performance?
Scott Violet: It will have similar performance as other image-based look and feels. So, there is no reason a Synth image based skin should be any slower than our current XP look and feel.
bgalbs: Chet, will you take requests for this year's arcade game Java2D demo at JavaOne? My vote's for first level of Super Mario Bros. ;-)
Chet Haase: I'd take requests if I were doing another one. But I think I'm taking a break from my annual "write a game from my childhood" project.
herpgps: Intel 82865G on many of our business machines has given lots of problems regarding corrupted drawing, as far back as 1.4.0.
Chet Haase: I've seen problems on this card, too, but I don't know of any particular outstanding issues today. It'd be great if you could submit a bug/testcase so that we can fix any problems you are having.
JavaGeek: You talk much about 1.6, but 1.5 just came out! Are you moving directly from 1.5 to 1.6, or are you following the usual path of 1.5.x for a while?
Scott Violet: Yes, we're moving directly to 1.6. The goal is to have major releases (1.6, 1.7) every 18 months and to only do update releases in the interim (1.5.0_01, 1.5.0_02). The good news is that we (the engineers) have more say over what goes in the update releases. For example, we've fixed the Windows look and feel to use Tahoma in an update release as well as a couple of tabbedpane bugs that community was bumping into. Now, this doesn't mean a free-for-all in the update releases, but it does mean we can address some problems faster than we previously have been able to.
cjn: The problem is filling a non-rectangular region with a gradient. Because clip regions are not anti-aliased,copyImageis inadequate, so AFAIK a (data-copying)TexturePaintis needed. Needless to say I'd be even happier with anti-aliased clip regions, but my understanding is that would require full screen anti-aliasing, which isn't planned?
Chet Haase: No plans for FS AA. Sounds like your options are limited for now. You might play around with doing AA just on border lines between the texture and the outside (so instead of a full texture paint, do adrawImage()with a clip rect that's inside the AA border you want, then do some other effect/filter/blur/composite/whatever for the border area). Just a random thought.
Dan: I am working on a integrated circuit layout tool. I currently draw objects to aJPanel, but have wondered if drawing to a different component, does the component type (JPanelvs.JLabel, for example) have any affect on the drawing speed?
Scott Violet: Component type should not effect rendering speed. In general useJPanelfor containment, andJComponentfor custom widgets. Also, watch the value ofisOpaque. If you're opaque, make sure you invokesetOpaque(true)or overrideisOpaqueto return true, that will make it so you avoid having to paint the parent during repaints.
codecraig: As far as the "dockable" framework...there is an open-source one (created for anyone to use)..called FlexDock. Any chance that an open-source project like that would be "accepted" by you guys? Or do you always create the solutions "home-made?"
Scott Violet: There are a bunch of them out there now. If we do a docking framework we will review those that are available and possibly work with the authors of some of them. Depending upon the scope we may also run a JSR for it.
markyland: What profilers do you recommend for profiling a Swing-based application?
Scott Violet: I've had good experience with optimizeit. In certain cases I'll also use-Xrunhprofor-Xprof.
codecraig: I have noticed painting problems when usingJTabbedPane. It seems that sometimes components within other tabs of a tabbed pane will "show through" to the first tab, until moving the mouse out of theJTabbedpane(causing a repaint). Any thoughts on this?
Scott Violet: Sounds like a bug, if you could submit a test case we'll look into it.
Dan: What issues have top priority Java2D in 1.6?
Chet Haase: Performance, performance, performance. Then some work on performance. The main thing that's always a priority for 2D is that we have the functionality and performance necessary to support the kinds of capabilities that applications and toolkits (Swing) need to write modern applications. So, for example, this means that applications in the 6.0 timeframe will probably rely more and more on anti-aliased text, which means we'd better find a way to make that faster. And applications are starting to play with translucent effects, which means we need to make sure that translucency support is accelerated as well. And any native look & feel work in Swing must be well-supported by the performance of 2D images and rendering. Samples of the kinds of things we are working on (besides general bug fixing and quality issues) include Single Threaded Rendering (huge wins for performance by not having to swap rendering contexts and by buffering up rendering requests to handle them all at one time) and rewriting the DirectX pipeline on Windows. These should both make GL and D3D much better in 6.0 in general (faster, more robust).
scottd: A JSR for commonly used components would be a good idea, there is too much duplication of effort in the desktop space.
Scott Violet: Thanks for the comments!
jvaudry: Is there any advantage to doing your repainting in ainvokeLater()?
Scott Violet: Repaint is almost the same asinvokeLater(new Runnable(){public void run() {component.paintImmediately();}}); I can't think of a good reason why you would want to doinvokeLater, than repaint.
bgalbs: How closely do y'all track the emerging Longhorn stack? Do you anticipate the Java/Swing/Java2D stack being superior to the .NET/WinForms stack in terms of EoD and competitive in terms of performance? Do you actively compare current (in pre-release builds) and planned features in Longhorn and plan matching/better functionality in Java 6/7?
Chet Haase: We're tracking Longhorn regularly. We actually feel that we have much to offer already that is on a par with what you can do there. One of the tricks is making sure that it is easy enough to write such applications in Swing; we're thinking about that one. Some of the performance stuff that the 2D team is working on is in this arena: making sure that we support the look & feel, font, translucency, and rendering operations that will be necessary in such a world with the performance people would expect.
JavaGeek: What about improvements to regular Swing components, likeJTable? I have a case where I need to 'freeze' two or more columns so they don't scroll off, and currently there's no easy way to do this.
Scott Violet: For 1.6 we want to do table sorting, highlighting and filtering. JDNC has this now, but it's so useful it should be in core. Column freezing has come up a lot as well, but it's secondary to sorting.
Rob: Any idea when we'll get a list of the JSRs that will be in Mustang?
Chet Haase: I believe the Mustang Umbrella JSR will be released real soon now ... but I'm afraid I don't know the date off-hand. That will have the JSRs in it.
Rob: Has there been any talk of new default models for Swing components (JTable,JList, etc...) based on the collections framework? The default models seem old and behind modern structures.
Scott Violet: Yes, although I'm not sure if this will take the form of new models, or the existing models taking collection classes. This and generification is on the list for 1.6.
swankjesse: Hey Rob:Glazed Listsbinds Swing models to the collections framework.
Scott Violet: Thanks for the pointer, we'll be sure and look there.
Dan: ForJTable, please, please, please, also give us asimpleway to size a column to best fit the contents (that is, without us writing the explicit code).
Scott Violet: I assume you want a method you can call at any particular time to have this happen, versus us doing it all the time?
craig-adh: Apologies if you have already covered this but I only just got a chance to join. The application I am responsible for receives and displays video footage from digital CCTV servers; I receive a stream of JPEG images which I decompress and draw to the screen. Until recently, Swing has been out of bounds (because I was being PJava compatible) but I can now re-implement it. Our main problem currently is when the images are scaled up to fill a high-resolution display. What would you recommend I look at to maximize performance in this case?
Chet Haase:Intermediate Images: If you are scaling the images to the same size more than once, scale them once to a temp image and then just calldrawImage()on that image. Wayyyyyyy faster than having us scale it on the fly each time. But if you are just displaying each scaled image once, then there's probably not much else you can do to improve performance since you're probably going through our software loops and we're going as fast as we can. We're working on hardware acceleration for this for DirectX/Windows for 6.0, but it's not in 5.0. OpenGL has acceleration for this in 5.0; you'll have to enable GL explicitly to try it. Also, you might try disabling DirectX acceleration on Windows to see if that affects scaling performance (sometimes way faster to do software rendering to a software back buffer than a VRAM back buffer):-Dsun.java2d.ddoffscreen=false.
MDR-EdO: Well we've quickly come to the end of our session. I want to thank everyone who participated today. I thought we had an excellent range of questions. And of course, I'd like to thank our guests, Chet and Scott, for their expansive answers.
JavaGeek: Thanks!
markyland: Thanks guys...good chat.
Guest: You guys rock! Thanks for all the info! Can we have some of you guys come talk about Swing Mon - Fri?? ...Swing is great, and learning the details about it (and how to make applications better, i.e. not be "slow" as everyone says) is so much fun! Thanks.
Chet Haase: Thanks for participating today; great chat! Lots of questions (too many to answer all of them - sorry if we didn't get to yours).
Scott Violet: All right, thanks for all the questions. Sorry if we couldn't answer them all. If you wish to continue any of the discussions please do so on theSwing forum on javadesktop. Thanks again!
MDR-EdO: Moderator signing off. The forum is now unmoderated.
'Java' 카테고리의 다른 글
| Jakarta Project (0) | 2006.09.14 |
|---|---|
| Ant 1.7: Using Antlibs (0) | 2006.08.30 |
| Sun Java Development Kit on FC5 (0) | 2006.08.29 |