On Oct 26, 2009, at 1:10 PM, Jean-Daniel Dupas wrote:
What do you expect as rectangle ? drawRect: parameter is the
smaller rectangle that contains all rect marked as dirty.
If you want to exact list of dirty rects, you can query it using the
-getRectsBeingDrawn:count: methods.
This is mo
Am 26.10.2009 um 17:44 schrieb Matthias Arndt:
or some reasons I still don't understand (Argh!) the drawRect:
method of my view didn't pass the right rectangle to the object
actually responsible for the drawing.
I mis-phrased that! There is no *technical* thing I don't understand
with the
Le 26 oct. 2009 à 17:44, Matthias Arndt a écrit :
Hi guys,
first let me thank you for all information and suggestions you
provided!
Am 26.10.2009 um 00:48 schrieb I. Savant:
That was entirely my fault, sorry. I have no idea where I got the
idea it was for a screen saver. I did not follo
On Oct 26, 2009, at 12:44 PM, Matthias Arndt wrote:
For some reasons I still don't understand (Argh!) the drawRect:
method of my view didn't pass the right rectangle to the object
actually responsible for the drawing. I just fixed the code to aim
for the best performance improvement: Don't
Hi guys,
first let me thank you for all information and suggestions you provided!
Am 26.10.2009 um 00:48 schrieb I. Savant:
That was entirely my fault, sorry. I have no idea where I got the
idea it was for a screen saver. I did not follow the link. In my
defense, a better description of th
On 26/10/2009, at 11:21 AM, Quincey Morris wrote:
On Oct 25, 2009, at 17:00, Graham Cox wrote:
I've found that caching to a PDF doesn't gain much performance wise
- a little, but not that significant. Since a PDF essentially
records whatever paths you create and rasterizes them, that's no
On Oct 25, 2009, at 17:00, Graham Cox wrote:
I've found that caching to a PDF doesn't gain much performance wise
- a little, but not that significant. Since a PDF essentially
records whatever paths you create and rasterizes them, that's no
surprise
Could well be, though it depends on whet
On Oct 25, 2009, at 8:00 PM, Graham Cox wrote:
But caching to a bitmap of some kind is a much bigger win, provided
you do it at the scale you need to draw it at (and recache if that
scale changes). Using CGLayer can generate really big speedups, so
that's worth looking into, but even the v
On 26/10/2009, at 10:48 AM, I. Savant wrote:
Quincey's suggestion to cache is right on the money: draw it with
bezier paths once, then only display the finished product as PDF
data. You could even separate it out into different 'overlays' for
each 'thread file'. That minimizes any redrawin
On Oct 25, 2009, at 7:48 PM, I. Savant wrote:
Quincey's suggestion to cache is right on the money: draw it with
bezier paths once, then only display the finished product as PDF
data. You could even separate it out into different 'overlays' for
each 'thread file'. That minimizes any redraw
On Oct 25, 2009, at 4:22 PM, Graham Cox wrote:
Really? It's not as if your computer has anything better to do.
Uhoh, we're entering philosophical debate territory.
First, it often takes a while to check out and compile a fresh copy of
our source tree. During this time my system is unusable
On Oct 25, 2009, at 7:22 PM, Graham Cox wrote:
screensavers should be low impact - personally, if a screensaver
uses more that about 10-15% cpu, I'll ditch it imediately
Really? It's not as if your computer has anything better to do.
Again: battery. Many of us are laptop users.
The OP
On 26/10/2009, at 10:07 AM, Paul M wrote:
screensavers should be low impact - personally, if a screensaver
uses more that about 10-15% cpu, I'll ditch it imediately
Really? It's not as if your computer has anything better to do.
The OP included a link to his project - it's not a screensave
On 26/10/2009, at 10:44 AM, Matthias Arndt wrote:
Am 25.10.2009 um 19:50 schrieb I. Savant:
How about creating 1 NSGradient instance for each color you want,
then creating one bezier path for each line. The path would describe
the outer edges of the pipe, then you'd *fill* it with the gradie
On Oct 25, 2009, at 14:44, Matthias Arndt wrote:
I'm nearly convinced to look into the gradients tomorrow, although
I'm afraid it won't result in a better performance: Empty the path,
calculate the angle, create the rect (with rounded edges), apply the
gradient and fill the path ... vs. thr
On Oct 25, 2009, at 5:44 PM, Matthias Arndt wrote:
Thanks for your response. I'm nearly convinced to look into the
gradients tomorrow, although I'm afraid it won't result in a better
performance: Empty the path, calculate the angle, create the rect
(with rounded edges), apply the gradient
Am 25.10.2009 um 19:50 schrieb I. Savant:
How about creating 1 NSGradient instance for each color you want,
then creating one bezier path for each line. The path would describe
the outer edges of the pipe, then you'd *fill* it with the gradient
at the desired angle, rather than stroking.
On Oct 25, 2009, at 2:42 PM, Matthias Arndt wrote:
My code draws lines some thousand times with different angles. I'd
like to have the lines to look similar to 3D objects. So currently I
draw each line segment three times:
1. one time with a thick line in black
2. the second time with a sli
18 matches
Mail list logo
