WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(3.77 KB, patch)
2012-11-28 13:49 PST
,
Min Qin
no flags
Details
Formatted Diff
Diff
Patch
(3.76 KB, patch)
2012-11-28 13:59 PST
,
Min Qin
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Min Qin
Comment 1
2012-11-28 13:10:22 PST
Created
attachment 176559
[details]
Patch
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
Created
attachment 176565
[details]
Patch
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
Created
attachment 176569
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug