|
From: Jun T. <tak...@kb...> - 2016-07-19 05:04:26
|
On 2016/07/18, at 2:08, Daniel J Sebald <dan...@ie...> wrote: > > Ah, yes, the vector-based pixels, but that is contrary to what you had concluded. In that mode, gnuplot is not using bitmap graphics, but vector graphics Yes, gnuplot creates the image as a vector graphics, but I've been thinking that other terminals, such as qt, internally convert it into a bitmap while aqua treats it as a vector graphics. But yes, even if this is the case, I don't know why aqua is so slow. >> It seems gnuplot uses about 0.5GB of memory for nonlinear3.dem. qt or wxt uses much smaller amount of memory. As for the CPU usage, Aquaterm.app uses about 95% of cpu while gnuplot uses 5 to 10% (100% means one cpu core is fully used). So it seems gnuplot creates large amount of data and send it to Aquaterm.app, while the latter uses large amount of cpu to process the data. I will do some profiling later (if I have some time). > I'm still surprised that this takes so long. If none of the demos in 'image.dem' and 'image2.dem' are glacial-pace slow, They don't use the 'pixels' option for plot. > What happens if you temporarily make this change in probably_tux.dem: > > #f(x) = norm((x-center)/sigma) > #g(x) = sigma*invnorm(x)+center > f(x) = x > g(x) = x Just the following command (without any scaling etc.) takes a long time: plot 'blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage pixels |