United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4737785 : Some fullscreen tests render no graphics without alt-tabbing out and back in

Details
Type:
Bug
Submit Date:
2002-08-27
Status:
Resolved
Updated Date:
2002-12-10
Project Name:
JDK
Resolved Date:
2002-11-16
Component:
client-libs
OS:
windows_nt
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:
1.4.1_02 (02)

Related Reports
Backport:

Sub Tasks

Description
Run the attached MyFSFrame test.  It's a simple test that creates a frame,
sets it to be the fullscreen window, and then runs in a tight loop 
rendering to a VolatileImage back buffer and copying that buffer to the
frame.

On my system, I get a blank white display when I run it.  if I alt-tab out
of the application and then back into it, I get the correct graphics
(a green background with some red text in it).

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.1_02
mantis

FIXED IN:
1.4.1_02
mantis

INTEGRATED IN:
1.4.1_02
mantis


                                     
2004-06-14
EVALUATION

Commit to mantis.
###@###.### 2002-08-27

The problem is our inconsistent creation and use of the DDraw Clipper object.
Currently, our code attempts to use the clipper on a window only if we are
not in fullscreen mode.  But since the same primary surface can be in both
fullscreen and non-fullscreen mode at different times in its existence, we
can run into problems with inconsistently assigning the clipper object and
its clip list.

Here is what the problem is with the attached test case:
- We create the primary surface at app startup time.  
- Since we are not yet in fullscreen mode, we create a Clipper object and
call SetClipper on the primary surface.
- We later go into fullscreen mode before having done any rendering onto
the ddraw surface.
- We eventually try to do a Blt from the VolatileImage buffer onto the 
window.  At this point, we try to set the clip list of the clipper object
to the hwnd (this uses the window's clip list).  However, our logic in the
AttachClipper() function says that if we are in fullscreen mode, do not set
the clip list.
- When we call Blt(), we get the error DDERR_NOCLIPLIST.

The problem is that we have assigned a clipper to the primary but have
given no clip list to that object.  The correct way to go about this would
be to either:
	- have no clipper object attached to the primary, or
	- set the clip list for the clipper object when it is attached
	to the primary.

I should note that we do not usually run into this situation.  For example,
alt-tabbing out and back in will cause the graphics to show up (and the
error to disappear).  Also, many other fullscreen apps run fine.  I think
the solution in those other apps is that either we are already in 
fullscreen mode before we create the primary that we later use for
fullscreen rendering (thus we have set no clipper on the primary) or
some rendering operation happens after setting the clipper and before
going into fullscreen mode so that we do set the hwnd value on the clipper
and it just happens to be there later when we are rendering in fullscreen mode.

The fix here is as suggested above: either do the complete solution to 
avoid using the clipper entirely in fullscreen mode (so make sure we do not
have a clipper attached to the primary at all when we enter fullscreen mode)
or to always attach the clipper, even in fullscreen mode.

Note that a clipper is not as useful in fullscreen mode; there are no other
windows around for us to draw over.  However, if any of our rendering operations take place outside the boundaries of the window, then we will get an error
without clippers that we do not get otherwise.

###@###.### 2002-08-27

Fix: set the clipper to NULL when entering fullscreen mode, set it to a valid
Clipper object when exiting fullscreen mode.

###@###.### 2002-11-06

A fix has been integrated into a 1.4.1 update release integration workspace.
Will mark "Fixed in release" field once the release version has been determined.
###@###.### 2002-11-26
                                     
2002-11-26



Hardware and Software, Engineered to Work Together