[cairo] Re: New API: cairo_surface_get_width/height

[Owen Taylor]

On Thu, 2006-06-08 at 19:47 -0700, Carl Worth wrote:
> I think it makes sense to add generic surface functions to query the
> width and height of any surface. There's a patch set below, (the
> attachment is suitable for piping to git-am [*]), to do this, and it
> can also be seen in the top four commits to the get-width-height
> branch of my personal cairo tree:
> 
> http://gitweb.cairographics.org/?p=users-cworth-cairo;a=shortlog;h=get-width-height
> 
> Now, we've never exported any generic surface-size query function
> before, presumably under the assumption that not all surfaces have a
> well-defined size. But I don't think that actually makes any sense. I
> think that cairo already requires all surfaces to have a well-defined
> size since it is possible to create a pattern from any surface and use
> CAIRO_EXTEND_REPEAT on that pattern which will necessarily need a size
> from the surface.
>
> Meanwhile, most surface_create functions already require an explicit
> size from the user. And the majority of those that don't effectively
> have an implicit size by being able to read a size from some object
> passed to the surface_create function. [See table below]
>
> Of the surface_create functions that accept an implicit size, all
> except for image_surface_create_from_png are from display systems
> about which I know basically nothing. Most of them appear to have
> robust means of querying the size of the underlying object, (glitz has
> get_width/height, beos has a Bounds function, and directfb has a
> GetSize function). The one that looks sticky is win32's GetClipBox
> function. There has been some discussion of this in the past and I got
> the impression that it might not be reliable as a means of querying
> the surface size, (that is, it may return 0,0 in some situations).
> 
> So, a question for the win32 maintainers: Do you see any problem with
> using GetClipBox to fix a surface size? I suppose if there is a fatal
> problem with this we could deprecate and switch to a
> win32_surface_create_with_size or whatever that accepts an explicit
> size. Or alternately, we could just augment with a
> cairo_win32_surface_set_size.

What's the motiviation here?

I don't think the argument about pattern sources is very compelling,
because using a window as a repeating pattern source is pretty much
nonsensical, for X, for Windows, or for any system. 

Obviously to implement fallbacks Cairo needs to be able to know the
"interesting" region of a destination surface, but we've already taken
care of that.

If the desire is simply to push the get size operations up the stack
to have them in a more logical place, then why not make the operation
optional and document that not all surfaces have a size?

For Windows in particular, if the surface is backed by a bitmap, you
can get that from the DC, and then get its bounds, but if it is
drawing directly to a Window, there is no easy way to get the
information, and I don't think it's sensible or useful information in
any case.

GetClipBox definitely doesn't return the size of the surface, it 
returns the box that it is interesting to draw on.

And requiring win32_surface_create_with_size() is really annoying to the
caller for no reason that I can see.
	 				   Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060608/5b0b9beb/attachment.pgp