<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - In accelerated drawing mode, ImageBuffer::putByteArray() should copy the bytes directly to the IOSurface backing store"
href="https://bugs.webkit.org/show_bug.cgi?id=157966">157966</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>In accelerated drawing mode, ImageBuffer::putByteArray() should copy the bytes directly to the IOSurface backing store
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Images
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>sabouhallawa@apple.com
</td>
</tr></table>
<p>
<div>
<pre>This is related to <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - toDataURL() uses stale data after putImageData()"
href="show_bug.cgi?id=65767">https://bugs.webkit.org/show_bug.cgi?id=65767</a> which was trying to fix the following problem:
Repro steps:
var img_a = canvas.toDataURL( 'image/png' );
// Allocate and set the colors of the 'data' buffer
context.putImageData( data, 0, 0 );
var img_b = canvas.toDataURL( 'image/png' );
Result:
img_a and img_b are identical although the context should have been changed when putImageData() is called.
What happened before the fix of this bug was the following: ImageBuffer::putByteArray() was doing the right thing by setting the bytes directly to the IOSurface backing store. The real problem was in the CG SPI CGIOSurfaceContextCreateImage(). Once this function is called, it caches the last returned image. Only when the context changes, by calling a CG drawing function, this cache will be invalidated. And any subsequent calls to CGIOSurfaceContextCreateImage() will force recreating the image. In the above scenario, context.putImageData() was not calling any CG drawing functions so the cached image was not thrown away.
Instead of putting the bytes directly into the backing store of the IOSurface, The fix <a href="http://trac.webkit.org/changeset/106836">http://trac.webkit.org/changeset/106836</a> was doing the following:
1. Putting the data into another ImageBuffer
2. Creating a native CGImageRef from this ImageBuffer
3. Drawing this native CGImageRef into the destination context.
This of course fixed the issue of getting a stale canvas image after calling putImageData() because drawing the CGImageRef into the context flushes the cache of CGIOSurfaceContextCreateImage(). And subsequent calls to this SPI was getting a fresh image.
The fix was kind of heavy hack. The fix should have been be one of the following:
1. IOSurface should be smart enough to know that the cached image, which is created by CGIOSurfaceContextCreateImage(), is invalid if the IOSurface backing store gets changed directly.
2. A new IOSurface API is needed to allow invalidating the IOSurface cached image manually. After putting the data in the IOSurface backing store, this function can be called so no stale cached image will be used.
3. A light weight fix can be used, for now, to force invalidating the IOSurface cached image.
This has been causing a performance issue with the canvas putImageData(). The Animometer 'Images' test has a very low score because of the current implementation of ImageBuffer::putByteArray()</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>