Leaks beim Bildexport [auch mit Vorschau.app?]

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Leaks beim Bildexport [auch mit Vorschau.app?]

    Hallo.

    Für jegliche Art der Hilfestellung werde ich dankbar.
    Mein NSView zeichnet in drawRect über CGContextRef mehrere importierte PDFs (Grafik) die mit einer CGImageRef mittels CGContextClipToMask maskiert werden.
    Es funktioniert.
    Es ist mir aber wichtig den Inhalt des Views in PDF-Format (Vector Qualität) zu vergrößern und als Bitmap zu exportieren.
    Dies funktioniert jedoch bis dato nur bedingt, obwohl die Bilddatei nach meiner Vorstellung mehrfach skaliert gesichert wird, werde ich bei dem Export mit 11 Memory Leaks Positionen überschüttet.
    Im Vorbereitung zum Bildexport erzeuge ich eine NSBitmapImageRep in der mittels NSGraphicsContext eine NSPDFImageRep von der View gezeichnet wird. Nach Instruments liegt genau da das Problem.

    Quellcode

    1. - (NSBitmapImageRep*) NSBitmapImageRepFromViewPDFdataWithDrawInRectWithScale:(CGFloat)scale_ fromView:(NSView *)view_
    2. {
    3. NSRect rect_ = [view_ bounds];
    4. float i_width = rect_.size.width;
    5. float i_height = rect_.size.height;
    6. NSData * data = [view_ dataWithPDFInsideRect:rect_];
    7. NSPDFImageRep * imgPDFRep = [NSPDFImageRep imageRepWithData:data];
    8. NSBitmapImageRep * bmpImageRep = [[NSBitmapImageRep alloc]
    9. initWithBitmapDataPlanes:NULL
    10. pixelsWide:i_width * scale_
    11. pixelsHigh:i_height * scale_
    12. bitsPerSample:8
    13. samplesPerPixel:4
    14. hasAlpha:YES
    15. isPlanar:NO
    16. colorSpaceName:NSCalibratedRGBColorSpace
    17. bitmapFormat:NSAlphaFirstBitmapFormat
    18. bytesPerRow:4 * (i_width * scale_)
    19. bitsPerPixel:32
    20. ];
    21. [bmpImageRep setSize:NSMakeSize(i_width, i_height)];
    22. [NSGraphicsContext saveGraphicsState];
    23. [NSGraphicsContext setCurrentContext:[NSGraphicsContext graphicsContextWithBitmapImageRep:bmpImageRep]];
    24. [[NSGraphicsContext currentContext] setImageInterpolation:NSImageInterpolationHigh];
    25. NSRect drawRect = NSMakeRect(0.0, 0.0, i_width, i_height);
    26. [imgPDFRep drawInRect:drawRect]; // MEMORY LEAK
    27. [NSGraphicsContext restoreGraphicsState];
    28. return bmpImageRep;
    29. }
    Alles anzeigen


    Getestet habe ich es auch mit ähnlichen Methoden in der CGContextDrawPDFPage(imageCGContext, page) im NSGraphicsContext angewendet worden sind, leider mit exakt gleichen Ergebnis: Export ok Leaks 11 .
    Es scheint arge Probleme zu geben, mit dem Aufzeichnen der NSPDFImageRep in die NSBitmapImageRep. Wie konnte man Dies umgehen?
    Setze ich nur die importierte PDFs in die View gibt's keine Leaks beim Export. Das gleiche wenn sich in der View nur die CGImageRef als Maske CGContextClipToMask befindet.

    Für jegliche Hilfestellung werde ich dankbar.

    Projekt läuft mit ARC. Xcode Version 5.1.1. MacBook OSX 10.8.5

    Rein Experimentell habe ich die View direkt mit

    Quellcode

    1. NSData * pdfdata = [view_ dataWithPDFInsideRect:[view_ bounds]];
    2. [pdfdata_ writeToFile: path__ atomically: NO];

    als pdf exportiert, um zu sehen was passiert im Instruments, wenn ich die Datei von daher mit Vorschau.app als vergrößerte Bitmap exportiere.
    Habe dann im Instruments die Vorschau.app aufgerufen um das besagte Bild zu exportieren, und siehe da : Die Liste von memory Lears war plötzlich voll.
    Was ist hier los, dachte ich mit Erstaunen und angespornt mit der "Entdeckung" untersuchte ich noch andere mac-eigene apps.

    - Vorschau.app ganze Menge Leaks schon beim Offnen.
    - iTunes.app Leaks.
    - App Store.app Leaks.
    - iPhoto.app Leaks.
    - Page.app Leaks.

    Mache ich da wirklich was falsch oder nimmt es mac bei eigenen apps mit der leaks nicht so genau.

    Mich hat es etwas, gelinge gesagt überrascht.
  • Auch Apples Framework ist nicht frei von Leaks.
    Allerdings hält sich so gut wie niemand bei der Erstellung eines PDF an den PDF Standard. (Was wohl auch nahezu unmöglich ist, da Kraut und Rüben dagegen total strukturiert und geordnet sind.)

    Wenn also Dein getestetes PDF eine mittelschwere Katastrophe ist und Vorschau etc.pp. diverse Verrenkungen machen müssen, um das Ganze trotzdem darzustellen, kann so etwas schon mal passieren.

    Ich finde es beispielsweise auch sehr schräg, dass der Finder SVG-Grafiken in der Vorschau anzeigen kann, Preview.app damit hingegen nichts anzufangen weiß.
    Und auch da: was InkScape an SVG-Grafiken produziert ist nicht dasselbe, was imagemagick als SVG erwartet. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Danke Marko.

    Marco Feltmann schrieb:

    Auch Apples Framework ist nicht frei von Leaks.
    Allerdings hält sich so gut wie niemand bei der Erstellung eines PDF an den PDF Standard. (Was wohl auch nahezu unmöglich ist, da Kraut und Rüben dagegen total strukturiert und geordnet sind.)


    Worschau.app habe ich in Instruments ebenfalls mit "banalen" Bitmaps .jpg getestet, leider mit fast gleichen Resultat.

    Was mein Export-Methode Problem angeht, werde ich dies erstmal so belassen und widme mich anderen "Baustellen" des Programms.
    Vielleicht werde ich später auf bessere Idee kommen oder vernünftigere Lösung finden.

    Ja die "kleinen" Wehwehchen :
    Keine Ahnung wie es bei 10.9 ausschaut, aber bei 10.8 der aufspringende horizontale Scroll-Balken wenn mal "ausgerechnet" der letzte untere Eintrag in diversen Listenfenstern eingeklickt werden soll ….. (?). ;)