« Return to Thread: Rasterizer clipping
Re: Rasterizer clipping
by Stephan Assmus
::
Rate this Message:
Hi Petr,
On 2009-05-09 at 12:00:45 [+0200], Petr Kobalíček
<kobalicek.petr@...> wrote:
> thanks for detailed reply:) I think that my code is right, because my
> geometry model is quite different. The x1,y1 positions are first and
> x2,y2 positions are last, but they are not in region. I think that RECT
> structure and HREGION from WinAPI should explain this:
>
> width = x2 - x1;
> height = y2 - y1;
>
> x2/y2 are not part of rect. Only code I'm not sure is -0.000001, I think
> that after your explanations it's not necessary, thank you.
Perfect, that's clear then.
> Currently my problem is different. Part of my thesis is multithreading
> and I don't know how to access scanlines from multiple threads, to be
> hones I don't know how AGG rasterizer exactly works. My current idea is
> to sweep_scanlines() from different threads, but this can't be done
> without locking, so my second idea is rasterizer for each thread and set
> different clipping for each. This will isolate and optimize access, but
> the path will be computed in all threads.
I think the best approach depends on your framework. Ie, do you render a
complete scene and want this to be multi-threaded? Or do you provide a
graphics API and render one path at a time or whatever the client code that
uses your lib can trigger to be rendered in one call into your lib? From
what I understand of what you are doing, it's the later. Then you have the
following problem: There is of course a slight overhead to managing the
threads, preparing jobs and triggering the threads to run. If the work to
be done falls below a certain threshold, it could be beneficial to switch
between single threaded rendering and multi-threaded rendering depending on
estimated penalty. However, this again could pose a problem. Assume client
code uses your library to render text, and enters your library for each
glyph in a text run. The glyphs are small and each time you may estimate
that it's better to stay single threaded, and effectively the whole glyph
run is rendered in a single thread as a result. To work around this, your
library could encourage "bulk rendering", where the client code schedules
more data to be rendered in one API call.
Anyways, in the background, I believe one "pipeline" per thread would be
best, ie including rasterizer, renderer, scanline storage, everything that
changes during rendering. And you need to be careful! For example, the
agg::path_storage has the iterator implementation built-in, IAW iterating
over a path storage is _not_ a read-only operation! So you should extract
that from the actual path storage, so that you can have one instance of a
path storage, but one iterator instance in each thread to iterate the same
path data.
Finally I would estimate that alternating scanlines based rendering should
yield the best balanceing effect. As you have already your own renderer
code where you iterate over scanlines, I would extend the AGG rasterizer
interface to be able to provide a "skip" value, ie the increment to be used
when iterating over scanlines during rasterizing. And the same for your
rendering implementation.
> BTW: The out of bounds problem is probably gone. I think I fixed it in
> BlitJit, but I'm not sure where exactly:)
Cool.
Best regards,
-Stephan
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general
On 2009-05-09 at 12:00:45 [+0200], Petr Kobalíček
<kobalicek.petr@...> wrote:
> thanks for detailed reply:) I think that my code is right, because my
> geometry model is quite different. The x1,y1 positions are first and
> x2,y2 positions are last, but they are not in region. I think that RECT
> structure and HREGION from WinAPI should explain this:
>
> width = x2 - x1;
> height = y2 - y1;
>
> x2/y2 are not part of rect. Only code I'm not sure is -0.000001, I think
> that after your explanations it's not necessary, thank you.
Perfect, that's clear then.
> Currently my problem is different. Part of my thesis is multithreading
> and I don't know how to access scanlines from multiple threads, to be
> hones I don't know how AGG rasterizer exactly works. My current idea is
> to sweep_scanlines() from different threads, but this can't be done
> without locking, so my second idea is rasterizer for each thread and set
> different clipping for each. This will isolate and optimize access, but
> the path will be computed in all threads.
I think the best approach depends on your framework. Ie, do you render a
complete scene and want this to be multi-threaded? Or do you provide a
graphics API and render one path at a time or whatever the client code that
uses your lib can trigger to be rendered in one call into your lib? From
what I understand of what you are doing, it's the later. Then you have the
following problem: There is of course a slight overhead to managing the
threads, preparing jobs and triggering the threads to run. If the work to
be done falls below a certain threshold, it could be beneficial to switch
between single threaded rendering and multi-threaded rendering depending on
estimated penalty. However, this again could pose a problem. Assume client
code uses your library to render text, and enters your library for each
glyph in a text run. The glyphs are small and each time you may estimate
that it's better to stay single threaded, and effectively the whole glyph
run is rendered in a single thread as a result. To work around this, your
library could encourage "bulk rendering", where the client code schedules
more data to be rendered in one API call.
Anyways, in the background, I believe one "pipeline" per thread would be
best, ie including rasterizer, renderer, scanline storage, everything that
changes during rendering. And you need to be careful! For example, the
agg::path_storage has the iterator implementation built-in, IAW iterating
over a path storage is _not_ a read-only operation! So you should extract
that from the actual path storage, so that you can have one instance of a
path storage, but one iterator instance in each thread to iterate the same
path data.
Finally I would estimate that alternating scanlines based rendering should
yield the best balanceing effect. As you have already your own renderer
code where you iterate over scanlines, I would extend the AGG rasterizer
interface to be able to provide a "skip" value, ie the increment to be used
when iterating over scanlines during rasterizing. And the same for your
rendering implementation.
> BTW: The out of bounds problem is probably gone. I think I fixed it in
> BlitJit, but I'm not sure where exactly:)
Cool.
Best regards,
-Stephan
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Vector-agg-general mailing list
Vector-agg-general@...
https://lists.sourceforge.net/lists/listinfo/vector-agg-general
« Return to Thread: Rasterizer clipping
| Free embeddable forum powered by Nabble | Forum Help |
