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 
Kev
How can it be so awful? Sorry, that’s the reaction I have now.
A new release of the Java Store is available 
http://store.java.com
http://java.sun.com/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 developers
outside of the US, improves integration with PayPal, improve performance, numerous smaller features, and bug fixes.
The Java Warehouse is also now open to 6 new countries to submit free apps :
The Java Warehouse is now open in 14 countries
http://java.sun.com/warehouse/overview/locations.jsp
A new intro video is also available
http://sun.edgeboss.net/download/sun/mp4/10b02249_00.mp4
The intro video is actually quite nice, visually. If Sun hires the same artist to design the application, it might actually be used by the casual audience.
yay, crashes for me on first attempt to run it
Java Web Start 1.6.0_17
Using JRE version 1.6.0_17-b04 Java HotSpot(TM) Client VM
User home directory = C:\Users\myusernamehere
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
m: print memory usage
o: trigger logging
p: reload proxy configuration
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
0-5: set trace level to <n>
----------------------------------------------------
server running at port: 56276
========== JNLP App Launcher starting ==========
current thread = AWT-EventQueue-0
in the app launcher. args =
printing an array: [Ljava.lang.String;@1878144
Len = 0
checking for Java 6 or higher
server running at port: 56276
======= verifying the cache =========
javafx is cached = false
javafx is cached = true
appstore is cached = false
progress: null version = null sofar = 0 total = 0 per = -1
progress: http://store.java.com/client/vector-client-gui2.jar version = null sofar = 0 total = 558419 per = 0
progress: http://store.java.com/client/vector-client-gui2.jar version = null sofar = 0 total = 558419 per = 0
progress: http://store.java.com/client/vector-client-gui2.jar version = null sofar = 11168 total = 558419 per = 0
progress: http://store.java.com/client/vector-client-gui2.jar version = null sofar = 22336 total = 558419 per = 1
Unable to load resource: http://store.java.com/client/vector-client-gui2.jar
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://store.java.com/client/vector-client-gui2.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadParts(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.downloadParts(Unknown Source)
at com.sun.jnlp.DownloadServiceImpl$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.jnlp.DownloadServiceImpl.loadPart(Unknown Source)
at com.sun.jnlp.DownloadServiceImpl.loadPart(Unknown Source)
at com.sun.services.appstore.launcher.JNLPAppLauncher.verifyCache(JNLPAppLauncher.java:207)
at com.sun.services.appstore.launcher.JNLPAppLauncher.realMain(JNLPAppLauncher.java:58)
at com.sun.services.appstore.launcher.JNLPAppLauncher.access$000(JNLPAppLauncher.java:28)
at com.sun.services.appstore.launcher.JNLPAppLauncher$1.run(JNLPAppLauncher.java:41)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by:
java.io.IOException: EOF reading band
at com.sun.java.util.jar.pack.NativeUnpack.start(Native Method)
at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)
at com.sun.java.util.jar.pack.NativeUnpack.run(Unknown Source)
at com.sun.java.util.jar.pack.UnpackerImpl.unpack(Unknown Source)
at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadParts(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.downloadParts(Unknown Source)
at com.sun.jnlp.DownloadServiceImpl$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.jnlp.DownloadServiceImpl.loadPart(Unknown Source)
at com.sun.jnlp.DownloadServiceImpl.loadPart(Unknown Source)
at com.sun.services.appstore.launcher.JNLPAppLauncher.verifyCache(JNLPAppLauncher.java:207)
at com.sun.services.appstore.launcher.JNLPAppLauncher.realMain(JNLPAppLauncher.java:58)
at com.sun.services.appstore.launcher.JNLPAppLauncher.access$000(JNLPAppLauncher.java:28)
at com.sun.services.appstore.launcher.JNLPAppLauncher$1.run(JNLPAppLauncher.java:41)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
sun.awt.image.PNGImageDecoder$PNGException: crc corruption
at sun.awt.image.PNGImageDecoder.getChunk(Unknown Source)
at sun.awt.image.PNGImageDecoder.getData(Unknown Source)
at sun.awt.image.PNGImageDecoder.produceImage(Unknown Source)
at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
at sun.awt.image.ImageFetcher.run(Unknown Source)
com.sun.javafx.runtime.main.Main
java.lang.ClassNotFoundException: com.sun.javafx.runtime.main.Main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.sun.services.appstore.launcher.JNLPAppLauncher.launchApp(JNLPAppLauncher.java:139)
at com.sun.services.appstore.launcher.JNLPAppLauncher.access$200(JNLPAppLauncher.java:28)
at com.sun.services.appstore.launcher.JNLPAppLauncher$2.run(JNLPAppLauncher.java:62)
at com.sun.services.appstore.launcher.JNLPAppLauncher$5.run(JNLPAppLauncher.java:215)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Just froze on the splash screen with no error message or response, lucky I had the java console enabled to see that it had crashed, had to kill it with the task manager.
The video says that in the US the Java Store is offered to over 50 million consumers, but who many of those actually use it? As a potential developer that’s what I’d like to know.
yes I am added. Never thought they would come to our small flanders 
Look likes you are using an older version from the log trace you submitted. Uninstall the version you have and get the latest version at store.java.com
ah, right you are, uninstalling and trying again makes it work.
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.
Dmitri
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.
The fix in 6u18 does help (the window isn’t repainted from scratch every time a single pixel is updated), but it doesn’t eliminate the problem completely (the need to update layered window).
Dmitri
[quote]but it doesn’t eliminate the problem completely (the need to update layered window).
[/quote]
Why? Can you explain? I’m very interested.
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.
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…
Dmitri
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.
Interesting stuff. Thanks for explaining.
Couldn’t be this workarounded by having alpha blended window just for the rounded frame and have another fully opaque window for content?
BTW, it would be nice to use shaped windows as well… on Linux when there is no compositing stuff it just add white border (sometimes pretty big).
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.
Cas