[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8165212 VolatileImage should not be compatible with Gra
From: Alexandr Scherbatiy <alexandr.scherbatiy () oracle ! com>
Date: 2016-10-28 11:27:17
Message-ID: cebf3746-953f-11a5-9a53-d36e0b0d4abd () oracle ! com
[Download RAW message or body]
350 if (!isAccelerationEnabled()) {
351 // Ideally there is no need to re-create a software
surface. But
352 // some OSs allow changes to display state at runtime.
Such a
353 // provision would cause mismatch in graphics
configuration of the
354 // display and the surface. Hence we re-create the
software surface
355 // as well.
356 sdBackup = null;
357 sdCurrent = getBackupSurface();
358 }
359 }
It seems that the surface is always recreated when the acceleration is
not enabled. May be it should be only done when the graphics
configuration transform scales are differ from the ones from vImg
graphics configuration?
Thanks,
Alexandr.
On 10/14/2016 1:38 PM, Prahalad Kumar Narayanan wrote:
>
> Hello Everyone
>
> Good day to you.
>
> Request your time in reviewing the fix for-
>
> Bug : JDK-8165212
>
> Title : VolatileImage should not be compatible with
> GraphicsConfiguration which transform is changed
>
> Description on the bug-
>
> . As per the bug, Volatile Image's graphics configuration is
> not updated when the host machine display's DPI is changed at runtime
> (while still running the java app). In addition, the method
> contentsLost() does not return true when display’s DPI is modified.
>
> . It is important to note that, the issue is not reproducible
> with D3D/OpenGL backend. It is reproducible with non-accelerated
> Volatile Image.
>
> Root Cause
>
> . A callback method- displayChanged() in
> VolatileSurfaceManager.java is invoked when display's settings (DPI)
> is modified.
>
> . The callback method, currently, updates the graphics
> configuration only for Accelerated volatile image. Graphics
> configuration is not updated for non-accelerated system memory based
> VolatileImage.
>
> . Until recently, there wasn't any need for updating graphics
> configuration for non-accelerated volatileImage. However, Win 8.1 and
> above provide feature to dynamically update the DPI setting (without
> requiring for log-off/ log-in), which causes the current bug.
>
> Bug Fix
>
> . First, the callback method is modified to update graphics
> configuration for non-accelerated volatile image also.
>
> . An update to graphics configuration might require re-creation
> of the surface. Especially, when the scale factor is increased. Hence
> the system memory based backupSurface is re-created here.
>
> . The above change is followed by change to Validate() API, so
> that the backup surface re-creation in displayChanged() method,
> correctly returns IMAGE_RESTORED from validate() API. This way, the
> code flow for non-accelerated Volatile Images behaves just the same
> way as accelerated volatile images.
>
> . Approximately 81 Jtreg test cases (that contained
> VolatileImage) were run on win7, linux, and osx. No new regressions
> have been found after the modification.
>
> . In addition, a manual test case has been provided to ensure
> the proper functioning of the fix
>
> Kindly review the changes and provide your suggestions
>
> Review link: http://cr.openjdk.java.net/~pnarayanan/8165212/webrev.00/
>
> Thank you for your time in review
>
> Have a good day
>
> Prahalad N.
>
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
350 if (!isAccelerationEnabled()) {<br>
351 // Ideally there is no need to re-create a software
surface. But<br>
352 // some OSs allow changes to display state at
runtime. Such a<br>
353 // provision would cause mismatch in graphics
configuration of the<br>
354 // display and the surface. Hence we re-create the
software surface<br>
355 // as well.<br>
356 sdBackup = null;<br>
357 sdCurrent = getBackupSurface();<br>
358 }<br>
359 }<br>
<br>
It seems that the surface is always recreated when the acceleration
is not enabled. May be it should be only done when the graphics
configuration transform scales are differ from the ones from vImg
graphics configuration?<br>
<br>
Thanks,<br>
Alexandr.<br>
<br>
On 10/14/2016 1:38 PM, Prahalad Kumar Narayanan wrote:<br>
<blockquote cite="mid:4d989226-9ef4-4d19-8e49-3f7fc2ba0c98@default"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hello Everyone<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Good day to you.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Request your time in reviewing the fix \
for-<o:p></o:p></p> <p class="MsoNormal"> Bug : JDK-8165212<o:p></o:p></p>
<p class="MsoNormal"> Title : VolatileImage should not be
compatible with GraphicsConfiguration which transform is
changed<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Description on the bug-<o:p></o:p></p>
<p class="MsoNormal"> . As per the bug, Volatile Image's
graphics configuration is not updated when the host machine
display's DPI is changed at runtime (while still running the
java app). In addition, the method contentsLost() does not
return true when display’s DPI is modified.<o:p></o:p></p>
<p class="MsoNormal"> . It is important to note that, the
issue is not reproducible with D3D/OpenGL backend. It is
reproducible with non-accelerated Volatile Image.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Root Cause<o:p></o:p></p>
<p class="MsoNormal"> . A callback method-
displayChanged() in VolatileSurfaceManager.java is invoked
when display's settings (DPI) is modified.<o:p></o:p></p>
<p class="MsoNormal"> . The callback method, currently,
updates the graphics configuration only for Accelerated
volatile image. Graphics configuration is not updated for
non-accelerated system memory based VolatileImage.<o:p></o:p></p>
<p class="MsoNormal"> . Until recently, there wasn't any
need for updating graphics configuration for non-accelerated
volatileImage. However, Win 8.1 and above provide feature to
dynamically update the DPI setting (without requiring for
log-off/ log-in), which causes the current bug.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Bug Fix<o:p></o:p></p>
<p class="MsoNormal"> . First, the callback method is
modified to update graphics configuration for non-accelerated
volatile image also.<o:p></o:p></p>
<p class="MsoNormal"> . An update to graphics configuration
might require re-creation of the surface. Especially, when the
scale factor is increased. Hence the system memory based
backupSurface is re-created here.<o:p></o:p></p>
<p class="MsoNormal"> . The above change is followed by
change to Validate() API, so that the backup surface
re-creation in displayChanged() method, correctly returns
IMAGE_RESTORED from validate() API. This way, the code flow
for non-accelerated Volatile Images behaves just the same way
as accelerated volatile images.<o:p></o:p></p>
<p class="MsoNormal"> . Approximately 81 Jtreg test cases
(that contained VolatileImage) were run on win7, linux, and
osx. No new regressions have been found after the
modification.<o:p></o:p></p>
<p class="MsoNormal"> . In addition, a manual test case
has been provided to ensure the proper functioning of the \
fix<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kindly review the changes and provide your
suggestions<o:p></o:p></p>
<p class="MsoNormal">Review link:
<a class="moz-txt-link-freetext" \
href="http://cr.openjdk.java.net/~pnarayanan/8165212/webrev.00/">http://cr.openjdk.java.net/~pnarayanan/8165212/webrev.00/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you for your time in review<o:p></o:p></p>
<p class="MsoNormal">Have a good day<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Prahalad N.<o:p></o:p></p>
</div>
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic