JDK-6223253 : VolatileImage.validate() always returns IMAGE_RESTORED on first attempt
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2005-01-29
  • Updated: 2008-02-06
  • Resolved: 2005-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b53Fixed
Related Reports
Relates :  
JDK-4902507 - double buffered X11 and GLX windows do not resize properly
Description
VolatileImage.validate() will always return IMAGE_RESTORED the first time
that method is called for an image.  One would expect that the return value
would be IMAGE_OK on the first try.  Note that this is only the case when
isAccelerated() returns true.

This is reproducible on 1.4.1, 1.4.2, 5.0, and Mustang.  I discovered this
problem while working on the fix for another bug (4902507).

To reproduce, compile and run the attached testcase on a system that has
accelerated VolatileImages.  You should see the following output:
in paint()...
creating VolatileImage
Iteration 0: validate returned IMAGE_RESTORED
Iteration 1: validate returned IMAGE_OK
Iteration 2: validate returned IMAGE_OK
Iteration 3: validate returned IMAGE_OK
Iteration 4: validate returned IMAGE_OK

###@###.### 2005-1-29 01:58:02 GMT
Comments
EVALUATION The current behavior was not necessarily intended, but rather developed in implementation. As the behavior matches the sample code, and probably at least some apps in the real world, it is difficult to change it now without risking app breakage. Specifically, if an app, like the sample code, relies in the IMAGE_RESTORED error code to do any painting into the VImg (including the first time), then our failure to return this error code would cause the image in those apps to be blank. I think it is safer to leave it as is; the only downside to the current behavior is that it is not completely obvious logic. However, in investigating this issue, it was discovered that there is a bug in the way we treat the software backup surface; when we fail to create an accelerated surface and use a sw backup instead, we do not necessarily return IMAGE_RESTORED from validate() the first time through. This means that apps that do rely on the current RESTORED behavior for that first paint may not be painting that backup image at all, resulting in blank images in this case. This has been noticed in one internal test already. We should leave the current semantics as-is (returning IMAGE_RESTORED the first time through validate()), but make sure that these semantics apply equally to sw backup surfaces and accelerated surfaces.
07-09-2005
EVALUATION The problem (if this is indeed a problem) is in VolatileSurfaceManager.validate(). If (sdCurrent != sdPrevious), we assume that the surface was restored, and the return value is IMAGE_RESTORED. On the first time through validate(), sdCurrent will be non-null, but sdPrevious will be null (it was never set). Therefore we treat this as an IMAGE_RESTORED case, instead of IMAGE_OK. Interestingly, we rely on the return value being IMAGE_RESTORED in order to know when to clear the surface with the background color. Weird. At first glance, the suggested fix would be to set sdPrevious=sdCurrent in initialize(), and then fix things up so that we make sure that initContents() is called the first time around. But the logic in this class is pretty fragile, so take care with this investigation. You break it, you bought it. ###@###.### 2005-1-29 01:58:02 GMT It appears that the example code in the VolatileImage javadocs relies on the fact the IMAGE_RESTORED is returned the first time around, so that it can render the contents whenever it sees IMAGE_RESTORED. So maybe this isn't a bug, but the intended behavior of the original author? ###@###.### 2005-1-29 02:05:32 GMT
29-01-2005