[quote]Has anyone else noticed that beta 2 will crash the VM on Windows if you use JFileChoosers and have broken shortcuts on your desktop?
[/quote]
I did. It doesn’t crash, it complaints about a million times about it. I even had same expirience with some app’s withouth opening JFileChooser (?!). On the side note, I’m unable to open anything with WebStart…something wiht io exception and stream closed.
Interesting, WebStart works for me.
With broken shortcuts, I get a VM crash after going through all the “Prblem with shortcut” dialogs… Win32ShellFolder… something or other kills things. Also related to the Finalizer thread and the initialization of a JFileChooser (that never has to be actually shown).
[quote]Interesting, WebStart works for me.
With broken shortcuts, I get a VM crash after going through all the “Prblem with shortcut” dialogs… Win32ShellFolder… something or other kills things. Also related to the Finalizer thread and the initialization of a JFileChooser (that never has to be actually shown).
[/quote]
Could you please try some of JGoodies (jgoodies.com) demos? I’m able to run some but not all with WS.
WebStart doesn’t work for me either.
Often it stops installing with the “Stream Closed”-Exception. Some links work, some sometimes (ofter a few clicks) and some never. Really strange.
The JGoodies demo dosn’t work for example.
Thought beta 2 got even better :-/
I can run all of them, but not always on the inital attempt. Sometimes I have to try several times.
I have to use a proxy here that I could not tunnel with WS1.4.2. So WS1.5 is a big progress concerning that.
- It has an annoying tendancy to pop up behind every
other window, making lots of test subjects think your app
has crashed.
It’s like that since… uhm… ever?
That dialog(*) is modal and it seems that it has null as parent. Therefore no notification if webstart gets the focus, no getting visible… but still it eats the focus.
(* that’s also true for the other one… what were they thinking?)
This is a generic Java AWT problem too. Dialog windows can be placed behind their parent windows, and hence unclickable on. It’s been like that for nearly a decade. Unbelievable.
Cas 
[quote]Is this how it is on windows already? It’s been so long since I used one of my own swing guis in windows I can’t remember ;)…
[/quote]
Nope, on windows you only get a clicked event if you press and release without moving the mouse, so the sequence of events you’ve got there appears to be broken. :o
The JFileDialog problem is a known bug (5049016, 5056514), will be fixed by fcs.
I’ve sent your feedback on other stuff to appropriate people…
I’m not exactly sure about the internals of Nvidia’s drivers, but depending on the pixel format used, they may allocate more than just 4 bytes per pixel. For pbuffers, you’ll have 4 bytes per pixel for the front color buffer, (possibly) 4 bytes per pixel for the back color buffer (yes, we shouldn’t be using double buffered pbuffers, but in some cases we can’t get around it), and another 1 byte per pixel for the stencil buffer. So now you’re talking about 12MB or more just for a pbuffer of that size. I’ll try to run some OGL tests on a low-VRAM config similar to yours to see if I can find ways to reduce the amount of VRAM used by pbuffers.
And yes, I would hope that if you reduced the size of your Swing window, everything would fit into VRAM and performance should improve; well, at least it won’t be painting a scanline at a time
Thanks,
Chris
[quote]Chris,
I did some tests by modifying the good old balls.jar source code by introducing an affinettransform that rotates the gfx context.
(using a Radeon 7000 agp 32Mb with "working"drivers (6.14.10.6396))
-
transforms are hw accelerated. That makes the fps jump very high (up to 100x comparing to “standard” java2d) !
-
bilinear interpolation does not work. Everything seems to be non interpolated.
-
the graphics output looks like being 16bit instead of 32 bit (i use a red shaded translucent ball for the test). This happens with managed images. Volatile images seem to be correct.
-
I can only use resolutions up to 640x480. I only get a black screen with higher resolutions.
I hope this helps.
I understand that the points 2,3,4 may be only driver/board problems, that’s why I think that some “Sun-made” testcode could be of great help in order to test the ogl pipeline both for performance and compliance.
[/quote]
Hi Mik,
Thanks for the testing results… Could you send me your modified source code, and your rebuilt balls.jar? We have a similarly modified version of that demo in-house that we use for testing all the time, and I haven’t noticed those issues that you’ve reported (but I haven’t done much testing on a Radeon 7000 either).
Thanks,
Chris
Having a little time and patience to spare, I tried again and waited for the slow updates long enough to do some experimentation.
It seems as though either:
- this is not a “not enough RAM” problem or:
- it is using a truly terrifying amount of RAM (i.e. there’s some serious bug somewhere)
I say this because with caching situations you expect performance to go:
- terrible -> very slight improvement -> sudden huge improvement - > very good
But I found that the performance was directly varying with window size, all the way down to 458x320 (window manager’s reported window size; actual java painted area probably 10-20 pixels narrower/shorter). Beyond that there’s so little visible it’s hard to tell, but I went all the way to 205x168 and was still getting window updates at a pitiful 8 FPS or so. Just slightly faster than I can reliably count them manually, but slow enough you can still see the window redrawing. And this is a TINY surface area (just 32,000 pixels or so :().
So. Maybe it’s not a RAM problem.
EDIT: all the below is using JDK 1.4.2_04 - this is a problem with OpenGL acceleration both in JOGL and LWJGL on 1.4. Just to make it clear
…but I have a similar problem with some OpenGL Java games that did get much better with resizing. I went from 0.25 FPS to 63 FPS fby resizing just a 100 pixels or so - although I’m not yet sure if it’s the “fewer pixels” causing this or just the act of “switching from MAXIMIZED state to RESTORED state”
look at my post here for info:
This is a JOGL game.
Although, as mentiuoned in that post:
- on the menu screen of the game, with VERY little being rendered, every pixel reduction increases performance (just like with vanilla swing using sun.java2d.opengl=true, as described in previous post)
- in the game itself resizing has almost no effect - I either have around 60 FPS or (if I maximize) all performance vanishes and it’s sub-1 FPS again.
So, in that game, I’m seeing BOTH behaviour consistent with mem problems AND non-consistent (going by my layman’s expectations).
So, perhaps my above comments suggesting this isn’t a mem problem are a sensible-but-incorrect guess, and in fact there’s just some kind of special case (for swing and for this game’s menu) where it behaves strangely.
PS: if you have any test apps you want me to run, I’d be glad to - I’d really like to track down the problem…I’d just like to understand what’s going on, even if the only possible solution is “never buy an nvidia laptop again” or similar 
[quote]Chris - please have a word with the desktop team and get them to turn on font antialiasing for font rendering by default. Java applications just look seriously unprofessional these days because of the blocky fonts.
[/quote]
Hi Cas,
In beta2, text is now antialiased by default for the GTK L&F if AA text is enabled on the desktop (see 5030990). We will likely do the same for the Windows L&F in a future release, but probably not for Tiger.
I imagine you’re mostly concerned with Windows (correct me if I’m wrong). Are you referring to the fonts used for the WinXP L&F or for Metal/Ocean? Are you comparing to the way fonts are rendered in native applications? When you say “blocky fonts”, are you referring to the bold fonts used by the Metal L&F? (In beta2, you can make Metal’s default font plain instead of bold. I can’t remember exactly the property used, but you can see how they did it in SwingSet2…)
Trust me when I say we work very hard to make text rendering quality a priority. We have more improvements on the way to improve quality of text on LCD screens, and to use AA text whenever appropriate (as mentioned above), and so on. Native L&F fidelity is a must if Java apps are to blend in seamlessly with the desktop environment…
Your other comments regarding WebStart have been forward to the appropriate folks. (No toenails were harmed, nor other violent actions pursued…)
Thanks,
Chris
[quote]In beta2, text is now antialiased by default for the GTK L&F if AA text is enabled on the desktop (see 5030990).
[/quote]
Hmm, that doesn’t really seem like a good idea from a quality point of view. I don’t know what others think but the built-in windows text antialiasing is pretty bad quality IMHO, it tends to just blur text and give a generally worse output. The result being that I don’t know many people who choose to actually use it.
Java text on the other hand looks so much better with AA, especially with the default bold text. It seems like you’d end up with only a minority of people actually seeing the text quality improve when really you want everyone to be using it. Perhaps an option in the Java control panel would be a better idea (and let it default to on).
It seems silly to spend so much time getting good, high quality font rendering and then not show it to the user by default.
You must antialias the fonts on the Windows L&Fs if the user has specified AA fonts for their desktop or the experience is extremely jarring.
Cas
[quote] You must antialias the fonts on the Windows L&Fs if the user has specified AA fonts for their desktop or the experience is extremely jarring.
[/quote]
Even at the expense of performance?
The problem with mouse events is described in this bugreport:
5039416: REGRESSION: Extra mouse click dispatched after press-drag-release sequence
The workaround is to use Motif toolkit:
-Dawt.toolkit=sun.awt.motif.MToolkit
[quote]The problem with mouse events is described in this bugreport:
5039416: REGRESSION: Extra mouse click dispatched after press-drag-release sequence
The workaround is to use Motif toolkit:
-Dawt.toolkit=sun.awt.motif.MToolkit
[/quote]
Thanks. I guessed someone else would have got there first with the bugreport
Yes, even at the expense of performance. If the user has already decided to antialias their Windows fonts then it’s not for Java to decide not do antialias them too on the basis of performance.
Besides, we really are talking about a tiny performance hit if you profile a typical Java client application.
Cas