# Faster alternative to Rasterize

I'm trying to do something similar to the genetic algorithm approximation of Mona Lisa with colored polygons (a brief description could be found here). With a population size of 60, each iteration took about 6s, which was too slow for the purpose. When I checked the profile, it seems that 90% of the runtime is spent on rendering the images, and more specifically, rasterizing the graphics. I tried turning Antialiasing off and on; it didn't make much of a difference.

Now I'm rendering the images with something like this:

v = RandomReal[{-256, 256}, {50, 3, 2}];
rp = Rasterize[Graphics[{Thickness[.0005], Opacity[0.2], Line/@v},
PlotRange -> 256], ImageSize -> 128]

(* Graphics[] -> 0.004s; Rasterize[] -> 0.14s*)


Is there any possiblities of an improvement in performance, other than rewriting my own function of directly creating rasterized image from the list of vertices? Thanks!

• Rasterizing anything with an alpha channel does seem to be slow. Is the Opacity[0.2] absolutely necessary in your case? – J. M.'s ennui Aug 10 '16 at 3:03
• You should add a minimal example for v to make the question self-contained. – Jens Aug 10 '16 at 4:23
• Why do need to rasterize? Why do need a special line thickness? Why don't you use AbsoluteThickness? Why do you need to set Opacity? What alternative to rasterization have you considered? We real need to know more than you are telling us. – m_goldberg Aug 10 '16 at 6:10
• This is a poor post, but a good question, and that's why I suggest to leave it open, but please edit you post soon to include necessary information as @m_goldberg has mentioned. – Wjx Aug 11 '16 at 15:19
• I added a sample v that has about the same timing on my machine. -- The comparison of the kernels times of Graphics[] and Rasterize[] is not really valid. The kernel only assembles the graphics expression; the front end is in charge of rasterizing it for the screen, and that time is not accounted for in Timing[] or AbsoluteTiming[]. – Michael E2 Aug 12 '16 at 14:20

This is a long comment to clarify some points in the question.

The comparison of the kernels times of Graphics[] and Rasterize[] is not really valid. The kernel only assembles the graphics expression; the front end is in charge of rasterizing it for the screen, and that time is not accounted for in Timing[] or AbsoluteTiming[]. One way to estimate the Front End timing is to use SessionTime[], but this very likely includes the time to do other things than rasterize the image. I am showing it, because I know no better way and no one has commented on it as yet.

The OP's way of timing, for reference:

v = RandomReal[{-256, 256}, {20, 3, 2}];
Rasterize[Graphics[{Thickness[.005], Opacity[0.2], Line /@ v},
PlotRange -> 256], ImageSize -> 128] // AbsoluteTiming // First
Graphics[{Thickness[.005], Opacity[0.2], Line /@ v},
PlotRange -> 256] // AbsoluteTiming // First
(*
0.137451
0.000014
*)


With SessionTime[]: It is important that the two SessionTime[] calls be in separate cells. Then the second cell will be sent to the kernel for evaluation only after the Front End has received the output from the first cell.

(* Cell 1 *)
time0 = SessionTime[];
Graphics[{Thickness[.005], Opacity[0.2], Line /@ v}, PlotRange -> 256]

(* Cell 2 *)
SessionTime[] - time0
(* Select both cells and execute simultaneously *)


I ran it several times. The timing ranged from 0.06 to 0.11 sec. What is not clear is whether the time includes GPU time (probably not, I would guess). If we increase the number of lines from 20 to 2000, Rasterize[] increases to 2.25 sec. and the FE time to only 0.40 sec. The FE increase could be due only to uploading more data to the GPU. It's clear that the graphics are rendered faster than 2 sec. If we raise the number of lines to 20,000, then Rasterize[] takes 13.8 sec. and the FE 1.93 sec., and it clearly takes a couple of seconds for the graphics to appear.