🚀 go-pugleaf

JD wrote:

>After using the VCL for a while, you get familure with
>working with a TCanvas and the TPrinter has a TCanvas so
>printing uses the same functions that one would use draw text
>on a control or a graph in a bitmap.

A Canvas is a DC. You just use DC methods. BitBlt, StretchBlt,
TextOut, etc,
See the Win32.hlp topics starting at 
"Printer Device Contexts Overview"
Also:
"Bitmaps, Device Contexts, and Drawing Surfaces"


> It also has functions
>that draw shapes and lines and copies blocks of pixels from
>one Canvas to another

See Clipping Functions and  BeginPath()

>. Once the Canvas is set, you print it by
>using NewPage or EndDoc.

Same.

>See, the thing that got me starting this thread was a test
>that I did. I generated a bitmap that had text and a pic and
>printed that using TPrinter::Canvas. When I put the litteral
>text into WordPad and added the pic, it printed slower than
>the Canvas test.

Well, what did you expect from an MS program, speed?

>Without the pic, they print about the same so I'm assuming
>that WordPad could be better optimized when printing graphics
>(and that bandwith has nothing to do with it). So ... if one
>print method can be faster than another, then why can't there
>be another, faster method and how do I know when I've maxed it
>out?

You'll never know.
We quit trying when it is "fast enough", or at least, as fast as we
can figure how to make it. Later, someone will show us a faster way,
and so we adopt it. We don't notice when newer/faster fails to come
along.
Just look at all the attempts at a FastMath library. (And how
different methods are faster on different processors.)

One thing I can tell you without reservation, is the VCL is going to
execute slower than direct coding. A call to a thin API wrapper is an
extra CPU pipeline flush, and is going to slow things down. Of course,
with the physical slowness of putting the dots on the paper, you
shouldn't notice it much.

In any case, pure Win32 API should in theory be at least as fast as
VCL. It might be faster if the VCL does things that aren't needed by
your particular application, or are redundant. (If you look at the ASM
generated by a C program, there are lots of redundant loads, which an
ASM programmer can optimise out. There might be similar happenings in
VCL generated code.)
Look at the VCL functions you are using, what they are doing
under-the-hood, and see if you can figure a simpler method or
eliminate some of the internal steps.
IIRC, the TCanvas has a DC property that you can use the API drawing
functions on. So use TPrinter for selection/setup and NewPage, but API
for drawing on the canvas.

The only speed boost I can think of right now is to align your BitBlts
so they start on whole bytes (dwords?) instead of half-a-byte.
That makes for blocky placement, but if you plan ahead for it, maybe
the BMP image could be pre-adjusted with whitespace to the left/right.

To get much faster, you'd probably need to drop to ASM, and
rewrite/replace the BitBlt et.al. funtions.