Created attachment 7262 [details] eps-file that is rendered very slow when antialiasing is turned on Antialiasing with -dGraphicsAlphaBits=2 or greater is extremely slow for the attached eps file. The problem also occurs when the eps file is converted to pdf and then displayed. Poppler/evince can render the pdf file fast. The eps file contains a diagram with many (ca. 3300) lines. I think the antialiasing algorithm is not optimized enough in ghostscript.
Sorry, the diagram contains 33000 and no only 3300 lines.
Re-file/assign to 'graphic library' owner since this does not appear to be an x11-specific issue.
Hi Robin, maybe you could provide some "sleepy" profiling results for this one.
Created attachment 7439 [details] problem.alpha.sleepy A profile, showing that a huge amount of time is spent in the scan conversion code.
Created attachment 7440 [details] problem.normal.sleepy A profile with no antialiasing for comparison.
The problem here is the inate complexity of Ghostscripts scan converter, and that fact that a different job is done with and without antialiasing. The file consists of a long path (33000 lineto's) which then gets stroked. In the non-antialiased case, this results in the line being stroked, and every section of that line filled individually. The scan converter therefore has typically around 4 edges to worry about at a time (left, right, top and bottom of each given segment). As the scan converter runs through the edge list, it has only 2 edges 'active' at any one time. In the antialiased case, the line is stroked entirely to give a path (naively with 33000*4 segments in it). This is then filled all at once. Because the line folds back upon itself repeatedly, we can easily have 66000 lines 'active' at once. No simple tweaks to the code are going to get past this problem. We need a basic change to the algorithm.
My prototype scan converter that doesn't use an active edge list manages this file in under 2 seconds (rather than > 15 minutes). The results aren't identical, but this is probably because I've never used the prototype scan converter with the antialiasing buffers before, and there may be some kinks to work out.
Related: bug #695906 http://bugs.ghostscript.com/show_bug.cgi?id=695906 (Added just so that the relationship isn’t lost or forgotten.)
This has been fixed by the new scan converter.