Есть GUI приложение, после того как оно завершает работу на экран выдается следующее сообщение

Цитата

Java2D Direct3D usage disabled by J2D_D3D env

Нигде не нашел упоминания о параметре J2D_D3D, только в awt.dll нашел такой текст. Никаких побочных эффектов не замеченно, просто интерестно что это значит.

Я нашел вот такую заметку в багах по JAVA

Код

I have installed mantis b19 on my xxxxx Portege 2000. When I attempts to bring up either the "Sun Java Console" or the "Plugin Control Panel" a grey area is displayed. If I move that area, the drop-to position remains grey, but the correct image is repainted into the old space. The new grey area is active, but all repaint actions occur in old position. Also, sometimes scrollbars behave in reverse manner: scroll up will scroll down. Even stranger, sometimes the horizontal scroll bars affect the vertical display. Applets contained within the browser windows and applications run fine. My laptop has the following configuration: 16 M Video ram w/ Trident Video Accelerator CyberBlade XP Ai1 graphics card windows 2000 SP2 At Jeannette's request, I ran with addtional settings (set in the Plugin Control panel) -Dsun.java2d.nod3d=true  Java Console now works fine,  Plugin Control Panel still incorrectly painting -Dsun.java2d.noddraw=true  both Java Console and Plugin Control Panel still behaving badly. Also, here is the information from the Java2D PlatformInfo tool: Platform configuration: CPU: Intel 32bit Single Processor Processor Speed: 746 MHz Operating System: Windows 2000 (version 5.0 Service Pack 3 (Build 2195)) DirectX version: DirectX 8.1 or greater DirectX display devices: Device 0:  Resolution (width x height x depth): 1600 x 1200 x 16  Device driver tridxp.dll version 5.0.2195.135 GDI display devices: Primary: Name = \\.\DISPLAY1, Description = Trident Video Accelerator CyberBlade XP Ai1  v5.9030 -008B.22ICD xxxxx@xxxxx 2003-03-31 Workaround  Disable Java2D's use of Direct3D at runtime by using the command-line flag -Dsun.java2d.d3d=false, for example: java -Dsun.java2d.d3d=false <class> You can use this same flag inside of plugin, in the "Advanced" tab inside the "Java Runtime Parameters" text field, enter the same flag info: -Dsun.java2d.d3d=false Since the plugin control panel can be rather messed-up and unusable due to this bug, you may also want to use the equivalent environment variable, J2D_D3D. To do this, pull up the System control panel, go to the Advanced tab and bring up the "Environment Variables" dialog box and enter a new variable named J2D_D3D with the value false.  Or you can do this same thing on a temporary basis by simply setting the variable on a command tool: set J2D_D3D=false Setting this environment variable for the system will also allow the control panel to work (since every Java execution will use the value of that variable to turn off d3d support and thus workaround this bug). xxxxx@xxxxx 2003-04-25 A straightforward workaround (at least in Win2K) is: Settings -> Control Panel -> Display -> Settings -> Advanced -> Troubleshooting. Set "Hardware Acceleration" to "Disable all DirectDraw accelerations ..." This workaround has a messaging advantage for customers: "The Trident video adapter has a problem and needs to be adjusted" (which is true) vs. "Java requires strange command-line flags to work right." The disadvantage is that it will affect performance of more than just Java. xxxxx@xxxxx 2003-06-26 Evaluation  I don't think this is a plug-in bug.  We need java2d team to take a look at this. xxxxx@xxxxx 2003-03-31 Mantis b19 plugin works fine on my Dell laptop.  Probably a specific issue with Trident video cards. xxxxx@xxxxx 2003-03-31 Definitely looks video-card specifc and seems to be tied to d3d functionality introduced in the changes that went into 1.4.1_02 and 1.4.2 b7; previous builds of both releases (and 1.4.0) work fine.  Also, using the d3d=false flag makes everything work (better workaround than noddraw). The effects are weird, though; they do not appear to have anything to do with the 3d functionality we are using (just drawing d3d lines).  Instead, it seems like simply enabling d3d for some drawing surfaces causes strange interaction between ddraw and gdi.  For example, scrolling on the crayons panel in SwingSet2 does nothing until you alt-tab to a different app, at which time the SwingSet2 window updates with several scroll/paint events.  It is as if the window events are locked out on that window which the app is in the foreground, but released when the app is backgrounded.  This artifact could explain why some graphics are being drawn in the wrong place while the window is being moved around; we are perhaps not getting the drawing event at the right time and then we are updating the screen some later time when the window has moved, thus the drawing is in the wrong place relative to the current location of the window. If this is a driver bug, there is no more recent version of the driver on the Toshiba site. Sill investigating. xxxxx@xxxxx 2003-04-03 I was able to reproduce the bug in a simple native app.  I forwarded the app to Trident tech support, who can hopefully shed more light on the subject. From what I've seen so far, it seems like the driver is enabling some sort of caching mechanism where they buffer up all calls into DirectX until one of a couple of events happen: locking/Unlocking the screen (which generally causes the DirectX pipeline to flush) or rendering a d3d primitive.  In our Java2D code, we do not necessarily perform either of these operations with any regularity.  DirectX operations are generally either rectangular fills (using ddraw), blts (using ddraw), locks (but not the screen on win2k due to a cursor flicker fix), or lines (using d3d).  Locking an offscreen buffer may also force a flush; I have not investigated that.  On this graphics driver, lines are disabled due to quality issues so we do not even issue the d3d calls. One other item that seems to flush the cache is forcing the window to the background; perhaps they want to make sure that an app is done rendering when other apps come to the foreground. in any case, there is nothing wrong that we are doing that is causing this situation; we appear to be causing it simply by creating the d3d device for the screen.  This puts the Trident driver in this strange mode. The only alternatives that I can think of so far for "fixing" this problem in Java2D include: - enabling d3d for the screen only if the application is fullscreen/ double-buffered.  This is the only situation in which we actually need d3d capability on the primary surface (since we generally do not perform direct3D operations directly to the screen; we use ddraw for Blts and GDI for direct rendering operations). A major problem with this (at least as far as risk-free fixes go) is that our single shared d3d context is created from the primary. So if we disable d3d for the primary surface, we need another mechanism for creating and sharing the d3d context.  This is not unsolvable, but it does involve risks and testing to make sure that we handle all situations robustly (such as losing the offscreen surface for which we have created that d3d context). - detecting the Trident video card and disabling d3d capabilities in native code automatically (similar to what we do for NT4, since there is no hw d3d support on that OS).  This is an ugly hack because I would rather avoid driver/card-specific fixes in our code and (more importantly) we do not actually know all of the devices which are affected by this odd bug.  if this driver is used by all Trident cards, then we should detect any trident video card and disable d3d.  On the other hand, if the bug is specific to a particular trident chip (and the driver for that chip), then disabling d3d for all trident cards is a bit extreme. My preference is the first fix above: find a way to share the d3d context without enabling d3d for the primary surface.  But given the time in the Mantis release and the testing required for this fix, I doubt this is a candidate for mantis. Note: I am assuming that the problem is coming from enabling d3d on the primary surface.  But I actually have not yet tested whether enabling it only for offscreen surfaces also triggers this problem.  if it does, then we are hosed for Trident overall, barring any clever fixes suggested by the folks at Trident.  I should nail this down to see whether this is even a fixable problem. I've attached a DevStudio project TridentD3DCrash.zip that has both the source code and executable for reproducing the problem.  Run the app. Then hit the F5 key to execute a series of ddraw blts to the screen (which won't appear on the problem platform).  then hit F6 to force a lock/unlock event, which should cause all of the pent-up ddraw commands to spew forth. hit F5 again (still not output).  now quit the app; after the window closes down, all of the ddraw commands spew forth onto the open desktop. xxxxx@xxxxx 2003-04-15 I've implemented a fix like the second one outlined above; we detect that we are running on a "Trident Video Accelerator CyberBlade XP Ai1" graphics card and automatically disable Direct3D support in Java2D (unless the user has specifically forced d3d support on via the command-line flag -Dsun.java2d.d3d=true or the environment variable J2D_D3D=true).  This appears to work on the problem platform, so we should integrate this fix possibly for 1.4.2 and definitely for 1.5 (until we have a better solution for 1.5). Note about the fix: we currently simply detect that there is one of these cards on the system and disable d3d support globally. This should work for this particular configuration, since the problem platform is a laptop that would never have multiple graphics devices on it.  But if we take this workaround approach for other problem cards/drivers, we should modify the fix to be multimon-friendly and simply disable d3d on the suspect devices and not the entire platform globally. xxxxx@xxxxx 2003-04-25

Спасибо за заметку, в понедельник попробую разобраться по подробней.

Поколупался я с этой проблемкой и вот что выяснил:
1) За наличие данного сообщения отвечала в переменная окружения J2D_D3D, а вот параметр командной командной строки -Dsun.java2d.d3d=true не оказывает никакого влияния. Причем кто установил такою переменную окружения я не знаю, но полагаю что JDK при установке (больше некому хотя видео карта у меня и не Trident), желания и времени сносить и ставить заново JDK не было (может как нибудь потом).
2) Никаких глюков и отличий в работе программ при значении данного параметра: true, false и вообще отсутсвии не замеченно.
3) Если верить данному bagreport-у то данный праметр отвечает за отключение использования Direct Draw, я взял пример из JDK BezierAnim и запустил его на рендеринг в полноэкранном режиме с выключенным и с включенным Direct Draw, результаты получились странные: 17.5 fps и 18.7 fps соответсвенно. По моим расчетам расчетам результаты должны разниться больше, или я чего то не понимаю?