[cairo] OS/2 backend support files

[Peter Weilbacher (Mozilla)]

Carl,

thanks for your wealth of comments. I will let Doodle reply to the ones about 
the code because he wrote it and can best explain what he had in mind. Some 
comments on the other stuff.

On Fri, 28 Jul 2006 10:42:15 -0700, Carl Worth wrote:

>On Sat, 22 Jul 2006 16:47:30 +0200, "Peter Weilbacher (Mozilla)" wrote:
>
>> - OS/2 does not allow to set png_CFLAGS in the environment (every
>>   variable is automatically uppercased). I don't know how to deal with
>>   this, so the OS/2ers either have to set CFLAGS including PNG specific
>>   flags
>
>I don't know anything about this one. Where do we use png_CFLAGS as an
>environment variable? (Which does look odd, if nothing else.)

I still have no clue where the "png_CFLAGS" are coming from but it probably 
has something to do with the autotools magic, I see none of them in 
configure.in but lots of them in configure (even though they don't appear in 
the dir with all the autotools), e.g. the line
  png_CFLAGS  C compiler flags for png, overriding pkg-config


>> OK, that's it for now. Let me know if I need to do anything more before
>> this can get into the main repository. Any more requirements to get this
>> into the 1.2 branch?
>
>There are a few small comments on the patch itself which I will make
>below. After those are addressed all we will need is someone who is
>willing to maintain this code, (Doodle? Peter?), who should then
>request a freedesktop account and then push the actual code into the
>tree. Account request instructions are here:
>
>	http://freedesktop.org/wiki/AccountRequests

As I am the one who wants (needs) this in the cairo repository, I guess I will 
do that.


>> +CAIRO_BACKEND_ENABLE(os2, OS/2, os2, OS2_SURFACE, auto, [
>
>The general rule is that we use "no" instead of "auto" for a backend
>while it is still experimental, (that is, until it is integrated and
>passes the test suite). That's so that users will get the warning
>about the experimental backend unless they explicitly ask to compile
>the backend with --enable-os2.

OK, at least that is easily fixed.


>> +cairo_public cairo_surface_t *
>> +cairo_os2_surface_create (HPS hpsClientWindow,
>> +                          int iWidth, int iHeight);
>
>I don't know much about what an HPS, but that function looks
>reasonable enough as an interface, (though I would use parameter names
>of hps (or maybe hps_client_window), width, and height).
>
>> +/* It's also a solution, but experience shows that if this happens*/
>> +/* from a non-PM thread, then it can screw up PM internals.       */
>> +/*                                                                */
>> +/* So, best solution is to set the HWND for the surface after the */
>> +/* surface creation, so every blit will be done from application's*/
>> +/* message processing loop, which is the safest way to do.        */
>> +
>> +cairo_public void
>> +cairo_os2_surface_set_HWND (cairo_surface_t *pSurface,
>> +                            HWND hwndClientWindow);
>
>The description here is confusing me. Is it saying that calling
>cairo_os2_surface_create without also calling
>cairo_os2_surface_set_HWND is fragile and likely not to work? In that
>case, should the HWND parameter simply be a required parameter to
>cairo_os2_surface_create and we can drop this second API?

I cannot say much about this because I haven't yet written a native OS/2 app 
that makes use of cairo but I can say that HWND as a requirement isn't 
possible because where in Mozilla the surface creation is called we don't have 
access to a HWND. What I think could be done is move the content of 
cairo_os2_surface_set_HWND() into an if-branch inside cairo_os2_surface_create 
that is only called if an HWND parameter is not passed as 0 (although I would 
hate to again fiddle with the respective Mozilla code now that it finally 
works).

   Peter.