I had problems with WM_ERASEBACKGROUND on this chipset, will resizing it background gets erased by native code, thats why i asked for a method to disable background erasing ( like in the JFrame's ).

remember this

Quote

TESTCASE3: run test16 with 1.6 update 3 on my 945G it flickers when i move another application ( like calc.exe ) over my window, its caused byToolkit.getDefaultToolkit().sync() when i comment out this line it does not flicker, or when i set sun.awt.noerasebackground=true.

Nice would be a function like setEraseBackground(boolean) for heavyweight components :-)

This flicker happens on my 945 (Dell Dimension 5100) but not on a 865 ( Dell Dimension 3000 )

Hmm. Looks like there was some bug which triggered this cascade of issues.

this flickering does not happen when i disable D3D or when i run it on a different pc, i removed Toolkit.getDefaultToolkit().sync() still flickering

Quote

Hmm. Did you override update() method in your hw component? Because if you didn't the default behavior is to clear the background:

yes have a look at java16, update is overwritten, its calling paint ( not at all the best, i use different code in my applets )

Actually much of the implementation between the pipelines is shared, only the native part that deals with particular API is different. So we do get the benefit of stable opengl pipeline code.

Good to know that not a lot engineering-effort was duplicated

Quote

The problem is that it appears that the manifacturers aren't that interested in quality opengl drivers on Windows - and only enough that big game titles work well. Unfortunately our stuff doesn't necessarily benefit from improvements made for games. There are big questions about future opengl viability on Windows.

Well the problem is some kind of chicken-egg. Almost nobody uses OpenGL on windows because hardware-support is bad, and hardware support is bad because nobody really uses it.My hope was that java would be some of those "law breakers", although I can understand that from Sun's POV its much more improtant to be commercially sucessful than to help OpenGL

Quote

Hey, no problems - you are entitled to asking these questions, you will be using this stuff (whether you want it or not =) . And these are legitimate concerns.

Well I want to use it of course and I am happy about the big leap foreward by jdk6uN.Although its dangerous to introduce such changes in an update release - Java is a bit late in the battle for desktop - so the descision to do all this stuff in an JDK-update release is what I call brave. Only the naming is in my opinion confusing - wouldn't be Java-6.1 exactly what everybody would expect?Well wel all know Sun's management only exist to confuse consumers and developers

FYI, b07 is out. It has a couple of important fixes:http://download.java.net/jdk6/6u10/promoted/b07/changes/jdk6uN-b07.html It significantly improves performance of Netbeans (and other applications which use LCD and grayscale AA text simultaneously); and addresses issues on Intel chips (by disabling the pipeline - at least until the drivers problems are resolved).

Will it be possible to disable background erasing on native frames ? at the moment this can be done by specifying sun.awt.noerasebackground and sun.awt.erasebackgroundonresize.

my program will run as applet and application, so i cant set the global noerasebackground options :-(

I have a application which will disable the frame decoration and draw its own non rectangular frame, problem is the white rectangular native background, swing is doing it, why not allow other swing like things this also ?

When you derive my test16 Frame from JFRame, no native background erase takes place, but when i resize ( make it bigger ) then its erasing the background strange behaviour.

What i need is native window ( a awt frame ) which can disable native background erasing in all cases, so i can develop for e.g. a program which has a non rectangular window ( for e.g. a java clock :-) ).

On some gfx cards window resizing flickers ( check my last post its a nvidia card which is having this problem ), on a resize the native background erase is triggered, if a awt frame has a function like

I know this is an old topic, but I just tried 6u10 and am pretty excited about the results I'd been working on some visualizations for a media player I'm writing for class (I'm doing gui, system architecture, and.. yep, anything visual - others are doing playback and xml library representation). So, the most cpu intensive visualization I was working on used something like 30% cpu before u10 and something like 5% after. I'm drawing lots of translucent BufferedImages to a VolatileImage and then drawing that to the screen. Some screens for fun, 'cause it's kinda perty (the numbers are a countdown btw, not fps - and the crappy image quality is because I only have Paint here ):<br>

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