il@csri.toronto.edu (Indra Laksono) (05/25/89)
The company I work for is developing a product under PM and OS/2.
On an Apricot 386 with 4 MB, the performance of programs written
for PM has been surprisingly slow. On one example, I had to simply
display a 1024x800 bitmap into a 512x400 window. It took four
seconds if I use GpiBitBlt, but only requires < 2 secs if I shrinked
the image into a 512x400 image first. If I use a very rough estimate
by knocking out all even bytes and even rows, the screen update is
immediate (<1sec). Of course, the ratio of 1/2 means I had it easy,
but GpiBitBlt could have checked for easy 'squeezing' and taken
appropriate action.
Somehow, I have the idea that many parts of PM could still be
improved to gain performance improvements of several orders of
magnitude.
Other than that, it is a reasonably nice environment to work in.
Warning though: if you think that the 64K segment problems has
gone away with 286 OS/2, think again. Using bit arrays is at
best Kludgy.
Example::
With DosAllocHuge, you can allocate lots of mem to a huge
pointer, but there is not much that you can do at the high
level with this array. We have DosOpen, DosRead, (or fread
at a slightly lower level), but there was NO DIRECT WAY to
say: read a large bitmap from disk. You have to loop through
and do getc (char by char), this not too bad if we consider
that the os is smart enough to keep a buffer, but is not very
elegant.
However, I like it, despite the shortcomings.