http://bugs.winehq.org/show_bug.cgi?id=60265 --- Comment #3 from werner.bundschuh@pm.me --- Follow-up measurement from the real world document, with the two attached patches applied and the subdivision depth instrumented. The document triggers 6805 calls to d2d_geometry_resolve_beziers(). 6759 of them need no splitting at all. The problematic object is one figure: bezier segments before splitting: 6994 bezier segments after splitting: 10109 growth factor: 1.45 maximum subdivision depth: 8 (the cap) average subdivision depth: 0.92 Two things worth noting for the review of patch 2/2: - The depth cap is what does the work. It binds -- the maximum depth is exactly the cap value -- and without it those pairs run to the float exhaustion depth of 25. Seventeen further levels of halving on the affected pairs is what produced the runaway; before the patches the figure had passed 900,000 vertices and the process was killed by the OOM killer at 66 GB of virtual memory. - The segment budget (16x the initial count) never triggered, not once in the whole session. With a growth factor of 1.45 it is nowhere near. It is a backstop, not the mechanism, and could be dropped or raised freely without affecting this case. With the patches, selecting the object takes 2-5 seconds instead of never completing, and the rendering is visually correct. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.