United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6298243 : OGL: scrolling is extremely slow in Swing apps in Mustang (Nvidia only)

Details
Type:
Bug
Submit Date:
2005-07-18
Status:
Resolved
Updated Date:
2008-02-06
Project Name:
JDK
Resolved Date:
2006-07-17
Component:
client-libs
OS:
windows_xp
Sub-Component:
2d
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0,6
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

Description
On Nvidia's Windows drivers, glCopyPixels() operations are
extremely slow when performed on pbuffers (or more accurately, those with
render-to-texture capabilities).  This means that copyArea() operations are
very slow for VolatileImage destinations on Windows when the OGL pipeline
is enabled.  And now with the gray rect fixes in Mustang, Swing performs
scrolling operations directly on the backbuffer (instead of on the screen as
before), which means scrolling is unusably slow when the OGL pipeline is enabled
on Windows.
###@###.### 2005-07-18 16:13:07 GMT

                                    

Comments
EVALUATION

It turns out that Nvidia did not in fact fix the first issue (slow glCopyPixels()
for pbuffers on Windows); apparently they marked it fixed without actually
resolving the problem.

We have been communicating with Nvidia over this issue for a number of months
in the hopes that they would fix these issues in their drivers, but it appears
that the issue is hardware related (due to the way textures are stored on
nv3x boards and earlier, basically any board earlier than the GeForce 6xxx
series), and any workaround they apply to try to speed up glCopyPixels()
probably will not meet our needs.  They have told us that the problem does not
apply when using the GL_ARB_texture_rectangle extension since those textures
are stored more efficiently, so to workaround the performance issue we could
start using the GL_TEXTURE_RECTANGLE_ARB target instead of GL_TEXTURE_2D.

While this requires a number of changes in our OGL pipeline, it seems to be
the only viable way to work around the problem in the short term, and at least
it has the added benefit that we will now use less VRAM since we can store
rectangular images directly instead of padding up to pow2-sized textures.
This extension is available on Nvidia boards going back to the GeForce 2 series
and on ATI Radeon 8500 and above.  (We've had support for the
GL_ARB_texture_non_power_of_two extension since Tiger, but that extension is
only available on very new hardware, like GeForce 6xxx.  So we will continue
to prefer that newer extension when it is available since it allows for
non-pow2 textures and the GL_REPEAT mode, which we use in our TexturePaint
acceleration code, whereas GL_REPEAT is not supported on
GL_ARB_texture_rectangle.)

The original synopsis of this bug was:
  OGL: copyArea is extremely slow for pbuffers on Nvidia drivers (Windows only)
but the larger issue here is that scrolling (and dragging internal frames)
in Swing apps is unusably slow since the gray rect fix was integrated in
Mustang b32.  So while the copyArea() performance issue has been reproducible
since Tiger, the more visible performance problem is the slow scrolling
behavior, which is a regression in Mustang, so I am going to update the
synopsis appropriately and mark this as an important regression:
  OGL: scrolling is extremely slow in Swing apps in Mustang (Nvidia only)

We should try to fix this for Mustang if possible, since the OGL pipeline
is essentially unusable on Nvidia hardware for end users of typical Swing apps.
                                     
2006-06-15
EVALUATION

The first issue (162467: glCopyPixels() slow for pbuffers on Windows) is
supposedly fixed in Nvidia's 85.xx series, but those aren't yet publically
available.

The second issue (174034: glCopyPixels() slow for FBO destinations) is
still pending.  Nvidia is investigating a fix for their 90.xx series drivers,
but nothing is set in stone.  I'm hoping that this will be resolved soon as
it's the only issue preventing us from turning on our FBO codepath by default
in Mustang.

I'll leave this bug open until driver fixes are publically available for both
of these issues.
                                     
2006-03-02
EVALUATION

This issue was filed against Nvidia's drivers a few months ago under incident
number 162467.  I also discussed the issue with driver engineers from Nvidia,
and they understand the impact, but claim it is a difficult issue to fix in
their drivers for render-to-texture surfaces (especially when the source and
destination regions are overlapping).  I will continue to pursue this issue
with them, but in the meantime I have filed this bug report as a placeholder
for comments about this problem.

This problem also affects FBO surfaces on Nvidia's drivers (on all platforms)
because they are treated just like render-to-texture surfaces, as described above.
So far, we have not been able to find a way to work around this problem in the
JDK.
###@###.### 2005-07-18 16:13:08 GMT
                                     
2005-07-18
WORK AROUND


###@###.### 2005-07-18 18:41:02 GMT
                                     
2005-07-18



Hardware and Software, Engineered to Work Together