Re: Stupid question: Flood Fill
Re: Stupid question: Flood Fill
- Subject: Re: Stupid question: Flood Fill
- From: Public Look <email@hidden>
- Date: Mon, 24 Nov 2003 22:43:01 -0500
On Nov 24, 2003, at 9:36 PM, Jens Bauer wrote:
Hi all,
How do I [path floodfill] ?
:)
I don't think you can. Flood fill is fundamentally a raster operation
and Quartz 2D is fundamentally a vector system. Flood fill makes no
sense in a coordinate system that is not tied to pixels, and flood fill
would be unlikely to work with a printer.
[deleted]
In fact, I already feel bad about what I've done so far.
I remember each drawing command, so that I can reproduce the drawing
correctly, when it's going to be printed. Even worse, I've just
refreshed the display using these vector commands, rather than saving
them in an image, and I tell you, it's slow.
I'd like having the possiblity for zooming by just scaling the
coordinates, but what on earth should I do? NSBezierPath is way too
slow here.
The approach you describe is basically the way every vector drawing
application works including Adobe illustrator, Corel Draw, and AutoCad.
The trick is to store the vector commands efficiently and to redraw as
little as possible each time redrawing is needed. You will run into a
particularly nasty side effect of the Quartz 2D rendering system;
performance of drawing degrades as the square of the number of segments
in a path. This results from the fact that Quartz has to test every
segment for intersection with every other segment in order to draw
transparency and anti-aliasing '"correctly". You are probably right
that NSBezierPath is way to slow, and all of the Quartz 2D (Core
Graphics) will also be too slow for the same reason. Your only hope if
you expect to use Quartz at all is to store individual line segments in
your application's data structures and draw them all separately.
Unfortunately, the will make filling complex shapes very difficult.
Apple has succeeded in making an API for beautiful graphics but made it
virtually useless for anything complex due to its performance
characteristics.
Would OpenGL render smoothly when printing ?
As far as I know, it is not possible to print with OpenGL at all short
of rendering to a giant image and printing that. OpenGL is not device
independent.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.