Sun contacted me about SingSong and I tried putting an app in the store. They even provided people I could contact with problems. It took many iterations and bug reports to finally get it going. The submission site is terrible.

Ditto with me with Tiltilation. I still don't have it working and I have lost hope of it ever doing so. I found it really hard to have a 2 way developer conversation with the other side in this too - spent ages trying to say that if Tilt didn't work then could they try another LWJGL app just to test the machine. I've just given up now, though I still get regular reminded emails from warehouse :/

This release brings a number of new features such as account creation into the client, provides the ability to preview your apps using the store view for developersoutside of the US, improves integration with PayPal, improve performance, numerous smaller features, and bug fixes.

I know this will fall on deaf ears (again) but please please make the app stop using translucent/shaped windows (at least on Windows). This slows the app down by a factor of 10x. All the (supposed) prettiness in the world isn't worth it.

And this is supposed to be fixed in a near to be released Java 6 update? I mean the translucency performance issue?

If Sun engineers are trying to reach other Sun engineers using JGO, it's probably a last resort and not very likely to happen.

Having said that, I can only hope they really make this thing a success. It is a concept that is very likely to make serious money -- once they get the basics right. Maybe fire the bunch and bring in some new blood.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

There are two steps in "repainting" a translucent Swing window on Windows. First is to render swing stuff into the swing back buffer, the second is to update the window representation using win32's UpdateLayeredWindow.

Prior to 6u18 on any update we'd repaint whole window into the backbuffer. So even if you had a blinking cursor, it'd re-render the whole thing. So that's fixed in 6u18 (btw, you could try it out http://download.java.net/jdk6/binaries/ ) - it only repaints what's needed into the persistent back-buffer. This does help, especially if repainting itself is costly (like in case of javafx apps where there could be effects and transforms and stuff).

But we still have to copy whole back buffer into the layered window. AFAIK there's no way to update only a part of layered window., so the whole window has to be updated every time. The sucky part is that the swing backbuffer could be in vram, which means that sucking it in and copying into a layered window through system memory could be very slow (better on pcix bus, which is where we let the hw-acceleration enabled for translucent windows). You'd think we could always disable hw accelerated backbuffer for translucent windows and save ourselves a vram->sysmem copy, but it'd be very bad for JavaFX apps which need hw acceleration for effects (otherwise they'd be done in software, which is even slower than copying from vram to system).

Basically, on Windows layered windows were never intended to be used for animated content (especially for larger sizes windows). This is from msdn docs for LayeredWindows: "For best drawing performance by the layered window and any underlying windows, the layered window should be as small as possible.". But apparently designers looove rounder corners on their windows, so they just slap it on without any concern for performance implications (just like they should), but engineering is supposed keep them in reign..

How come it was done like that from the start? and then taken this long to fix? My small app of 300x300 pixel window I don't see any problems with high cpu, so hopefully the window is small enough.

Because when this feature was being developed (in 6u10) there wasn't enough time/people to do it properly, and also this way was the safest with fewest changes, I believe. Once the swing/awt dudes had the time to redo this, it was first done in jdk7, baked there for a while, and finally was deemed safe enough to backport to 6uN train, and only after all prerequisites (other bugfixes this one relied on) for this fix were first ported (which was a major pain). Even then the fix introduced a few regressions in 6uN code, which had to be patched a few times, which is why the full fix didn't make it into any earlier releases.

The problem is that the Windows API for this is all-or-nothing I think - a window is either translucent or it's an opaque rectangle. To make a central bit opaque would effectively mean AWT would have to manage such a window as a composite of smaller bits and pieces - doable but probably pretty hard without a lot of fiddly code. And I expect the Java APIs to actually state that some bit of the window is opaque whilst the rest is not would look quite grim too.

The problem is that the Windows API for this is all-or-nothing I think - a window is either translucent or it's an opaque rectangle. To make a central bit opaque would effectively mean AWT would have to manage such a window as a composite of smaller bits and pieces - doable but probably pretty hard without a lot of fiddly code. And I expect the Java APIs to actually state that some bit of the window is opaque whilst the rest is not would look quite grim too.

Yeah, that was on my mind. I've seen it in some SW that added shadows to windows and it worked pretty well, even if the shadows were actually 4 smaller windows along the sides. AWT shouldn't do this automatically... just manage the windows yourself in such way. However AWT could do automatic shaping of translucent windows on fully transparent areas to avoid the issue on Linux I mentioned.

I would expect translucent/shaped windows to be much faster and easier to do on Windows Vista/7. Isn't there any new DWM API that allows you to implement this with better performance?

Not much in terms of performance difference on Vista/7 layered windows, but you're right, they do have some DWM APIs which make it sort of possible, but only when D3D is used, and only when Aero is enabled. This is certainly a possibility. For Prism (the new JavaFX graphics stack) we'd probably only support translucent windows on W7/Vista through those APIs.

Yeah, that was on my mind. I've seen it in some SW that added shadows to windows and it worked pretty well, even if the shadows were actually 4 smaller windows along the sides. AWT shouldn't do this automatically... just manage the windows yourself in such way. However AWT could do automatic shaping of translucent windows on fully transparent areas to avoid the issue on Linux I mentioned.

I don't think this is AWT's job. The developer could use the provided API to determine if translucent windows are supported or not, and modify app's behavior accordingly.

One issue is with JavaStore is that currently there isn't a JavaFX API that tells you whether translucent windows are supported or not.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org