On that example "nbcairo" runs almost as fast as "Xlib" on my machine (and
faster than the example runs in Windows).
This is one of the sorts of example where the planned changes for 2.8.0
will make "cairo" faster than "nbcairo".
On Mon, 7 Apr 2008, Roger D. Peng wrote:
> For what it's worth,
For what it's worth, one area where I've noticed a big change is when I add to
a
plot in a for loop. For example, many calls to 'lines' or 'points'. Notice:
> x <- runif(2000, -1, 1)
> y <- runif(2000, -1, 1)
> X11(type = "cairo")
> plot(0,0)
> system.time(for(i in 1:2000) points(x[i], y[
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> Martin M x 2,
>
> Yes, no news in either of your most recent messages. That's a really
> ugly plot, though, and I do want to protest about either of these
> being worth doing fast.
The data motivating the original report was from quality assessment
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Sat, 5 Apr 2008 19:31:43 +0100 (BST) writes:
BDR> Martin M x 2,
BDR> Yes, no news in either of your most recent messages. That's a really
ugly
BDR> plot, though, and I do want to protest about either of these being
w
Martin M x 2,
Yes, no news in either of your most recent messages. That's a really ugly
plot, though, and I do want to protest about either of these being worth
doing fast.
On my home system
> F <- ecdf(rnorm(1))
> system.time(plot(F))
user system elapsed
1.343 0.035 1.410
> x
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Sat, 5 Apr 2008 16:27:52 +0100 (BST) writes:
BDR> On Sat, 5 Apr 2008, Martin Morgan wrote:
>> Yes, thank you, this fixes the problem for me.
>>
>> As a follow-up, and again with my ignorance of where
>> processi
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Sat, 5 Apr 2008, Martin Morgan wrote:
>
>> Yes, thank you, this fixes the problem for me.
>>
>> As a follow-up, and again with my ignorance of where processing is
>> actually occuring, it seems like the X11 window content is drawn
>> directly rath
On Sat, 5 Apr 2008, Martin Morgan wrote:
> Yes, thank you, this fixes the problem for me.
>
> As a follow-up, and again with my ignorance of where processing is
> actually occuring, it seems like the X11 window content is drawn
> directly rather than being drawn to a buffer and then blit on to the
Yes, thank you, this fixes the problem for me.
As a follow-up, and again with my ignorance of where processing is
actually occuring, it seems like the X11 window content is drawn
directly rather than being drawn to a buffer and then blit on to the
screen -- the original appearance of the plot is s
I think I have found this -- if so, it was an X11 timing issue and we
needed to re-read the X11 window size at a later time. Please
try r45102 or later.
On Fri, 4 Apr 2008, Prof Brian Ripley wrote:
> On Thu, 3 Apr 2008, Martin Morgan wrote:
>
>> I apologize if this is too obscure to reproduce,
On Thu, 3 Apr 2008, Martin Morgan wrote:
> I apologize if this is too obscure to reproduce, or some idiosyncratic
> aspects of my system. If I create a plot, e.g.,
>
> > plot(1:10)
>
> I get a graphics device as expected. I then click on the 'zoom' box on
> my X11 window, so the window expands to
I apologize if this is too obscure to reproduce, or some idiosyncratic
aspects of my system. If I create a plot, e.g.,
> plot(1:10)
I get a graphics device as expected. I then click on the 'zoom' box on
my X11 window, so the window expands to occupy the entire screen. The
plot is redrawn at t
12 matches
Mail list logo
