🚀 go-pugleaf

Hi fellow programmers,                                      Graz, 11.10.92

I got two (almost:-) short PM programming question:

1.) I want to modify the window title of the main window of my application
    using the following code in my ClientWindowProc:

               DosPostEventSem(hevStartMeasuring);
               sprintf(WindowTitle, "%s -- measuring", szAppName);
               WinSetWindowText(hwnd, WindowTitle);

    but this simply refuses to change the title. I already tried to
    use the HWND handle returned by the WinCreateStdWindow call in main()
    but no avail.

2.) My application requires a couple of bitmaps (the more the better) to be 
    BITBLT to the as fast as possible screen. I'm currently investigating 
    the following methods:

    a.) Read all bitmaps, build a hbm[] list and in a loop use:
 
              GpiSetBitmap(hpsMemory, hbm[i]);
              GpiBitBlt(hps, hpsMemory, .....);

    b.) Read all bitmaps, *PRESCALE* all bitmaps to the window size with

              hbmTmp = GpiCreateBitmap(hpsMemory, ......);
              GpiSetBitmap(hpsMemory, hbmTmp);
              GpiSetBitmap(hpsMemory1, hbm[i]);
              GpiBitBlt(hpsMemory, hpsMemory1, ......)
              GpiDeleteBitmap(hbm[i]);
              hbm[i] = hbmTmp;

        and use the same loop as above to display the bitmaps

    Method a.) has the advantange of not comsuming too much Ram (my bitmaps
    are 400x300 in 16 colors). Though, it is slow (0.48s per image scaled to
    640x354 on a Trident 8900c in 800x600x256) since the bitmap is scaled
    everytime it is displayed. BTW: I get 0.78s per image on a ET4000
    with the ORCH09 800x600x16 driver. The machine is almost the same.
    Peculiar!!

    Method b.) is VERY fast (0.12s as opposed to 0.48s above) but consumes
    *VERY* much RAM (which depends on the window size, of course, which is 
    supposed to be up to 1024x768). Still one problem with this method is
    that frequent resizings of the window (especially from large to small
    and back) causes information to be lost and thus would require the
    original bitmap to be saved and this would require still more Ram.

    Now I noticed, though, that the BITMAPINFO2 has an 'ulCompression' field
    which allows to specify HUFFMAN, and three different RLL compression
    methods.

    Now for my question: How is the GRE supposed to handle the compressed
    bitmaps? How can I create a compressed bitmap (I already tried it by
    just specifying a compression method for GpiCreateBitmap - but no go).
    I the PM supposed the handle compressed bitmaps itself?

    Any ideas anyone how to speed up the image update rate? Is it possible
    with the uncompression routine (if the PM has one anyway) I get a higher
    troughput than with method a.) above (resizing everytime) ?
    
Thanks to everbody who read my posting up to this point :-) and thanks
for any replies in advance. 

Bye for now -- Tom Leitner, Joanneum Research, Graz, Austria, Europe
               Internet: tom@piassun1.joanneum.ac.at
               Fido:     2:316/7.91