Raw Drawing questions

Hi all.

I’ve made a small library of antialiased drawing primitives (DrawAALine,
DrawAAThickLine, DrawAACircle, DrawAAThickCircle). They look pretty good,
but the trouble is they are drawn laboriously with PgDrawIPixel, and
consequently are much slower than the eqivalent PgDraw functions.

My current approach is calculate, set alpha, draw pixel, set alpha, draw
second pixel, calculate, …
A few questions to help speed it up:

  1. Am I right in assuming that the time taken in the PgDrawIPixel function
    is large compared to any calculations I might be doing (maths co-pro makes
    even fp maths quick), even if I am using a PtOSContainer? I’m also assuming
    the PgSetAlphaBlend function doesn’t have a high overhead in itself.
  2. Is PgDrawPixelArray significantly faster than the equivalent number of
    PgDrawPixel 's? Currently I’m drawing the pixels as I calculate them, but I
    could put them into 256 arrays (one per alpha level) and use
    PgDrawPixelArray when I’m done with the calculations. Trouble is it would
    take up a heap of memory to hold all the pixel values, so I’d want it to
    make a considerable difference.
  3. Any other suggestions to help speed it up?

And to help with the interface to the functions:
3. Is there any way to retrieve the current drawing settings, such as
alpha-blend level, line thickness and fill color?

Thanks,
Stuart Harding

P.S. These circles and lines look pretty good. If anyone is interested in
using them, send me an email and I’ll either email it or post it on here
when the library’s done.

Hi Stuart,

Stuart Harding <sharding@gil.com.au> wrote:

I’ve made a small library of antialiased drawing primitives (DrawAALine,
DrawAAThickLine, DrawAACircle, DrawAAThickCircle). They look pretty good,
but the trouble is they are drawn laboriously with PgDrawIPixel, and
consequently are much slower than the eqivalent PgDraw functions.

My current approach is calculate, set alpha, draw pixel, set alpha, draw
second pixel, calculate, …
A few questions to help speed it up:

  1. Am I right in assuming that the time taken in the PgDrawIPixel function
    is large compared to any calculations I might be doing (maths co-pro makes
    even fp maths quick), even if I am using a PtOSContainer? I’m also assuming
    the PgSetAlphaBlend function doesn’t have a high overhead in itself.

That would depend on your calculations. :slight_smile:

PgSetAlphaBlend itself does not have much overhead. However, using
alpha blending will slow down the graphics driver drawing functions.

  1. Is PgDrawPixelArray significantly faster than the equivalent number of
    PgDrawPixel 's? Currently I’m drawing the pixels as I calculate them, but I
    could put them into 256 arrays (one per alpha level) and use
    PgDrawPixelArray when I’m done with the calculations. Trouble is it would
    take up a heap of memory to hold all the pixel values, so I’d want it to
    make a considerable difference.

Yes, PgDrawPixelArray should be faster for a number of reasons:

  • There’s a non-trivial amount of “preamble” that goes on before each
    draw command is constructed and stuffed into the draw buffer.
  • Your draw buffer space is used more efficiently because you don’t need
    a separate command header for each pixel you draw.
  • You (probably) won’t change the draw engine state as often.
  1. Any other suggestions to help speed it up?

It’s generally faster to draw horizontal runs of pixels
(using PgDrawRect/PgDrawIRect) than random arrays of pixels.

If possible, avoid using alpha blending. For example, if you
know you have a constant background colour, you could use a gradient
palette.

I would also suggest that you profile your code to see how much
time your calculations are using.

And to help with the interface to the functions:
3. Is there any way to retrieve the current drawing settings, such as
alpha-blend level, line thickness and fill color?

Not really. You can write application-level code to track your current state.