Use SkSet to fix issue when pdf generates an exp number of resources.

The problem fixed - http://code.google.com/p/skia/issues/detail?id=940 - is that getResources will recursively obtain all child resource recursively without checking for duplicates.

If we have lots of duplicates, then we try to build a very large vector (exponential with the number of nodes usually) and sooner or later we end up using too much memory and crash.

A possible solution could have been to make sure resources do not have duplicates, but that requirement is impractical, and it this leaves the solution fragile, if there is any issue in the tree,  we crash.

When we emit the pdf, the large number of duplicates is not an issue, because SkPDFCatalog::addObject will deal with duplicates.

I have run the gm with --config pdf, and the images are 100% same bits, while the pdfs have the same size but some very small changes, the order of some objects.
Review URL: https://codereview.appspot.com/6744050

git-svn-id: http://skia.googlecode.com/svn/trunk@7883 2bbb7eff-a529-9590-31e7-b0007b416f81

1 files changed, 3 insertions, 3 deletions

diff --git a/tests/PDFPrimitivesTest.cpp b/tests/PDFPrimitivesTest.cpp
index 6e7d61676d..8041a8f389 100644
--- a/tests/PDFPrimitivesTest.cpp
+++ b/tests/PDFPrimitivesTest.cpp
@@ -21,10 +21,10 @@
 
 class SkPDFTestDict : public SkPDFDict {
 public:
-    void getResources(SkTDArray<SkPDFObject*>* resourceList) {
-        resourceList->setReserve(resourceList->count() + fResources.count());
+  virtual void getResources(const SkTSet<SkPDFObject*>& knownResourceObjects,
+                            SkTSet<SkPDFObject*>* newResourceObjects) {
         for (int i = 0; i < fResources.count(); i++) {
-            resourceList->push(fResources[i]);
+            newResourceObjects->add(fResources[i]);
             fResources[i]->ref();
         }
     }