Bug 142032 - Cleanup RenderSVGResourceClipper class.
Summary: Cleanup RenderSVGResourceClipper class.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Said Abou-Hallawa
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-02-25 17:45 PST by Said Abou-Hallawa
Modified: 2015-02-26 10:41 PST (History)
4 users (show)

See Also:


Attachments
Patch (13.01 KB, patch)
2015-02-25 18:07 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff
Patch (12.96 KB, patch)
2015-02-25 18:28 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff
Patch (13.96 KB, patch)
2015-02-26 09:09 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff
Patch (13.93 KB, patch)
2015-02-26 09:48 PST, Said Abou-Hallawa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Said Abou-Hallawa 2015-02-25 17:45:03 PST
This bug to address Darin's comment in https://bugs.webkit.org/show_bug.cgi?id=141776#c5.

Comment on attachment 246862 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=246862&action=review

> Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:260
> +ClipperData* RenderSVGResourceClipper::addRendererToClipper(const RenderObject& object)

The pointer this returns is always non-null. This function should return a reference instead of a pointer.

> Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:264
> +    if (!m_clipper.contains(&object))
> +        m_clipper.set(&object, std::make_unique<ClipperData>());
> +    return m_clipper.get(&object);

This code does double hash table lookups. You just moved it, but the performance problem can be fixed, like this:

    auto& slot = m_clipper.add(&object, nullptr).iterator->value;
    if (!slot)
        slot = std::make_unique<ClipperData>();
    return slot.get();

That will only do a single hash table lookup. In the future we might invent even cleaner ways to write this.

We could also consider making this a HashMap<const RenderObject*, ClipperData> instead. If we did that, then the code would be even simpler:

    return m_clipper.add(&object, ClipperData()).iterator->value;

The map would be larger, because each slot would have an entire ClipperData object. And rehashing would be slower, but we would avoid the overhead of an additional memory block for every slot that is in use.
Comment 1 Said Abou-Hallawa 2015-02-25 18:07:50 PST
Created attachment 247379 [details]
Patch
Comment 2 Said Abou-Hallawa 2015-02-25 18:14:01 PST
(In reply to comment #0)
> This bug to address Darin's comment in
> https://bugs.webkit.org/show_bug.cgi?id=141776#c5.
> 
> Comment on attachment 246862 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=246862&action=review
> 
> > Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:260
> > +ClipperData* RenderSVGResourceClipper::addRendererToClipper(const RenderObject& object)
> 
> The pointer this returns is always non-null. This function should return a
> reference instead of a pointer.
> 

Done.

> > Source/WebCore/rendering/svg/RenderSVGResourceClipper.cpp:264
> > +    if (!m_clipper.contains(&object))
> > +        m_clipper.set(&object, std::make_unique<ClipperData>());
> > +    return m_clipper.get(&object);
> 
> This code does double hash table lookups. You just moved it, but the
> performance problem can be fixed, like this:
> 
>     auto& slot = m_clipper.add(&object, nullptr).iterator->value;
>     if (!slot)
>         slot = std::make_unique<ClipperData>();
>     return slot.get();
> 
> That will only do a single hash table lookup. In the future we might invent
> even cleaner ways to write this.
> 
> We could also consider making this a HashMap<const RenderObject*,
> ClipperData> instead. If we did that, then the code would be even simpler:
> 
>     return m_clipper.add(&object, ClipperData()).iterator->value;
> 
> The map would be larger, because each slot would have an entire ClipperData
> object. And rehashing would be slower, but we would avoid the overhead of an
> additional memory block for every slot that is in use.

Thanks for the advice. This change looks much better and cleaner than the code I modified. I changed the type of m_clipper to be as you suggested. ClipperData is a structure which only one item of type std::unique_ptr<>. So sizeof(ClipperData) is 8 and sizeof(ClipperData*) is also 8. So I think the map size will be the same with this change.
Comment 3 Said Abou-Hallawa 2015-02-25 18:28:34 PST
Created attachment 247385 [details]
Patch
Comment 4 Darin Adler 2015-02-25 19:13:00 PST
Comment on attachment 247385 [details]
Patch

Looks like this doesn’t compile on Windows. It seems that Windows is having trouble because it is compiling the assignment operator for ClipperData rather than a move operator. We might be able to fix this using std::unique_ptr<ImageBuffer> directly or as a typedef instead of wrapping it in a class.

Also, we don’t need to use WTF_MAKE_FAST_ALLOCATED in the ClipperData struct any more since we are not allocating it as a separate object on the heap.
Comment 5 Said Abou-Hallawa 2015-02-26 09:09:20 PST
Created attachment 247427 [details]
Patch
Comment 6 Said Abou-Hallawa 2015-02-26 09:48:31 PST
Created attachment 247429 [details]
Patch
Comment 7 WebKit Commit Bot 2015-02-26 10:37:47 PST
Comment on attachment 247429 [details]
Patch

Clearing flags on attachment: 247429

Committed r180685: <http://trac.webkit.org/changeset/180685>
Comment 8 WebKit Commit Bot 2015-02-26 10:37:50 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Radar WebKit Bug Importer 2015-02-26 10:41:12 PST
<rdar://problem/19971911>