[Webkit-unassigned] [Bug 98990] [Texmap][CSS Shaders] Enable CSS Shaders in TextureMapperGL

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Oct 20 20:17:16 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=98990





--- Comment #6 from Huang Dongsung <luxtella at company100.net>  2012-10-20 20:18:15 PST ---
(From update of attachment 169766)
View in context: https://bugs.webkit.org/attachment.cgi?id=169766&action=review

>> Source/WebCore/platform/graphics/texmap/TextureMapperLayer.h:72
>> +#endif
> 
> Why not have the renderer map as a member of TextureMapper, instead of virtualizing the holder?
> The patch would be a lot shorter and succinct if you did that...

Thanks for review. It's very reasonable concern.

This complexity is because of one requirement: destruction.

We must destruct CustomFilterGlobalContext when we navigate another page, because CustomFilterGlobalContext caches css shaders compiled programs. It is why RenderView holds CustomFilterGlobalContext in software path.
We must destruct CustomFilterRenderer when given RenderLayer dose not have the style including given custom filter. For example, javascript removes css shaders in the given element. It is why RenderLayer holds FilterEffectRenderer and FilterEffectRenderer holds CustomFilterRenderer in software path.
So I decides the root TextureMapperLayer holds CustomFilterGlobalContext like RenderView, and each TxtureMapperLayer holds CustomFilterRenderer like RenderLayer.

I had implemented both as a member of TextureMapper. I had troubles to destruct both in right time.

I wish TextureMapper holds both classes because it would be more succinct as you mentioned. If you give me ideas, I'll do that :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list