RESOLVED FIXED Bug 103555
Make LazyDecodingPixelRef inherit from skia::LazyPixelRef so that cc thread can access it
https://bugs.webkit.org/show_bug.cgi?id=103555
Summary Make LazyDecodingPixelRef inherit from skia::LazyPixelRef so that cc thread c...
Min Qin
Reported 2012-11-28 13:07:47 PST
Make LazyDecodingPixelRef inherit from skia::LazyPixelRef so that cc thread can access it
Attachments
Patch (3.76 KB, patch)
2012-11-28 13:10 PST, Min Qin
no flags
Patch (3.77 KB, patch)
2012-11-28 13:49 PST, Min Qin
no flags
Patch (3.76 KB, patch)
2012-11-28 13:59 PST, Min Qin
no flags
Min Qin
Comment 1 2012-11-28 13:10:22 PST
Hin-Chung Lam
Comment 2 2012-11-28 13:30:57 PST
Is Skia rolled already?
Min Qin
Comment 3 2012-11-28 13:39:56 PST
The skia change i made is in rev 168995, and webkit now is using 169895. So I assume the change has rolled already. (In reply to comment #2) > Is Skia rolled already?
Hin-Chung Lam
Comment 4 2012-11-28 13:44:28 PST
Comment on attachment 176559 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176559&action=review > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:94 > + m_mutex.lock(); Use MutexLocker lock(m_mutex). The mutex just needs to protect access to m_frameGenerator and m_scaledSize. We don't absolutely need a mutex here because they don't mutate but just for safety.
Min Qin
Comment 5 2012-11-28 13:49:35 PST
Min Qin
Comment 6 2012-11-28 13:50:17 PST
(In reply to comment #4) > (From update of attachment 176559 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176559&action=review > > > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:94 > > + m_mutex.lock(); > > Use MutexLocker lock(m_mutex). The mutex just needs to protect access to m_frameGenerator and m_scaledSize. We don't absolutely need a mutex here because they don't mutate but just for safety. Done
Hin-Chung Lam
Comment 7 2012-11-28 13:50:28 PST
Comment on attachment 176565 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176565&action=review > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:95 > + // TODO(hclam): check if only a particular rect is available in image cache. Whoops also WebKit doesn't use TODO(XXX), it's just TODO. Sorry I didn't point it out earlier.
Min Qin
Comment 8 2012-11-28 13:59:14 PST
Min Qin
Comment 9 2012-11-28 14:00:14 PST
(In reply to comment #7) > (From update of attachment 176565 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176565&action=review > > > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:95 > > + // TODO(hclam): check if only a particular rect is available in image cache. > > Whoops also WebKit doesn't use TODO(XXX), it's just TODO. Sorry I didn't point it out earlier. ah.... Sorry, missed that. Fixed now
Hin-Chung Lam
Comment 10 2012-11-29 14:13:58 PST
lgtm from me by the way.
Stephen White
Comment 11 2012-11-29 14:20:52 PST
Comment on attachment 176569 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176569&action=review OK. r=me > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:103 > + lockPixels(); > + unlockPixels(); Not sure I really get this, since you're going to have to lock again to use them, but I'm sure you know that. :)
WebKit Review Bot
Comment 12 2012-11-29 14:35:08 PST
Comment on attachment 176569 [details] Patch Clearing flags on attachment: 176569 Committed r136167: <http://trac.webkit.org/changeset/136167>
WebKit Review Bot
Comment 13 2012-11-29 14:35:12 PST
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 14 2012-11-29 18:24:09 PST
Re-opened since this is blocked by bug 103701
Min Qin
Comment 15 2012-12-04 17:33:45 PST
Hi, Stephen, Can you help me recommit this patch? A fix for the previous build fix is submitted in r170542 The current DEPS roll is at 171019 now. Thanks
Stephen White
Comment 16 2012-12-04 17:34:59 PST
Comment on attachment 176569 [details] Patch OK. r=me
WebKit Review Bot
Comment 17 2012-12-04 20:50:45 PST
Comment on attachment 176569 [details] Patch Clearing flags on attachment: 176569 Committed r136630: <http://trac.webkit.org/changeset/136630>
WebKit Review Bot
Comment 18 2012-12-04 20:50:50 PST
All reviewed patches have been landed. Closing bug.
Stephen White
Comment 19 2012-12-05 12:15:43 PST
Reverted r136630 for reason: Still breaking Chrome/Win Debug builds Committed r136728: <http://trac.webkit.org/changeset/136728>
Min Qin
Comment 20 2012-12-06 10:45:21 PST
Comment on attachment 176569 [details] Patch Hi, Stephen, sorry about this, but can you approve this again. Thanks. We believe the windows dbg bot failure is caused by that the lazy_pixel_ref.h is not built into the dll. So we split the file into a .cc and .h file. The fix is committed in r171375. And DEPS has rolled to r171376
Stephen White
Comment 21 2012-12-06 10:51:26 PST
(In reply to comment #20) > (From update of attachment 176569 [details]) > Hi, Stephen, sorry about this, but can you approve this again. Thanks. > > We believe the windows dbg bot failure is caused by that the lazy_pixel_ref.h is not built into the dll. So we split the file into a .cc and .h file. The fix is committed in r171375. And DEPS has rolled to r171376 Have you built windows debug (component build) locally?
James Robinson
Comment 22 2012-12-06 12:22:10 PST
(In reply to comment #21) > (In reply to comment #20) > > (From update of attachment 176569 [details] [details]) > > Hi, Stephen, sorry about this, but can you approve this again. Thanks. > > > > We believe the windows dbg bot failure is caused by that the lazy_pixel_ref.h is not built into the dll. So we split the file into a .cc and .h file. The fix is committed in r171375. And DEPS has rolled to r171376 > > Have you built windows debug (component build) locally? And if you aren't set up to do this, you can send a tryjob to the chromium win trybot (which is debug and component) to verify. Please do one or the other before attempting to land.
Min Qin
Comment 23 2012-12-06 13:58:53 PST
Hi, Stephen. Yes, I tried our new patch on windows dbg build, and it compiles fine now.
Stephen White
Comment 24 2012-12-06 14:00:23 PST
Comment on attachment 176569 [details] Patch Great, thanks. r=me
WebKit Review Bot
Comment 25 2012-12-06 14:22:25 PST
Comment on attachment 176569 [details] Patch Clearing flags on attachment: 176569 Committed r136891: <http://trac.webkit.org/changeset/136891>
WebKit Review Bot
Comment 26 2012-12-06 14:22:29 PST
All reviewed patches have been landed. Closing bug.
Hin-Chung Lam
Comment 27 2012-12-06 14:29:39 PST
Comment on attachment 176569 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176569&action=review > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:97 > + return ImageDecodingStore::instance()->lockCompleteCache(m_frameGenerator.get(), m_scaledSize); I don't think this is entirely correct, this method is used as a hint to see of the cache is there. So the code should be: const ScaledImageFragment* cachedImage = ...lockCompleteCache(); if (!cachedImage) return false; ... unlockCache(cachedImage); return true; Can you make another change to fix this?
Hin-Chung Lam
Comment 28 2012-12-06 14:30:27 PST
(In reply to comment #27) > (From update of attachment 176569 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176569&action=review > > > Source/WebCore/platform/graphics/chromium/LazyDecodingPixelRef.cpp:97 > > + return ImageDecodingStore::instance()->lockCompleteCache(m_frameGenerator.get(), m_scaledSize); > > I don't think this is entirely correct, this method is used as a hint to see of the cache is there. So the code should be: > > const ScaledImageFragment* cachedImage = ...lockCompleteCache(); > if (!cachedImage) > return false; > ... unlockCache(cachedImage); > return true; > > Can you make another change to fix this? If you don't do this it wil leak.. :(
Note You need to log in before you can comment on or make changes to this bug.