[cairo] request for cairo_win32_surface_get_width/height()

[Bill Spitzak]

Vladimir Vukicevic wrote:
> On 4/28/09 1:08 AM, Theo Veenker wrote:
>> Hi,
>>
>> I like to request cairo_win32_surface_get_width/height() to be added to
>> the win32 surface support. Cairo_win32_surface_create() uses GetClipBox()
>> to determine the size to be used for the surface. But when calling
>> cairo_win32_surface_create() from a WM_WINDOWPOSCHANGED or WM_SIZE
>> notification GetClipBox() initially returns a NULLREGION (although the
>> notification reports the actual window size) and then later it clip
>> region becomes valid. There is no way of telling which size the actual
>> surface has once it has been created. I can hack my way around it, but
>> having these APIs would be nice.
> 
> You really shouldn't be doing any rendering from WM_WINDOWPOSCHANGED or 
> WM_SIZE..
> 
>      - Vlad
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo

It would however be nice to access the size with code that is portable 
between X and Windows and also all other cairo targets. Currently fltk 
keeps the window size in static variables parallel with the static 
cairo_t, as programs certainly do need it. It seems wrong that this is 
redundant with info that is in the xlib cairo_t but I am forced to do 
this because the others don't have it.

Just like the X version, I think it is acceptable for the Windows 
implemenmtation to require the caller to handle the resize events and 
update the context itself (ie Cairo should not handle events or make 
Windows calls to get the size). This is easily hidden in toolkit support 
code.

It would be nice to have some more parity between cairo on the different 
platforms. The ability to change the size and target of an Xlib cairo 
context is very useful and on Xlib I use exactly one Cairo context, 
reusing it for every window and paint event. It would remove a lot of 
ugly code if I could do this on Windows and OS/X. Conversely, if such 
retargeting is a bad idea, the Xlib version should *not* be supporting 
it either, because it certainly encouraged me to use it!

-- 
Bill Spitzak, Senior Software Engineer
The Foundry, 618 Hampton Drive, Venice, CA, 90291, USA
Tel: +1 310 399-4555 * Fax: +1 310 450-4516 * Web: www.thefoundry.co.uk
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027