[cairo] Re: New API: cairo_surface_get_width/height

[Russell Shaw]

Owen Taylor wrote:
> 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.

In a CAD, drawing, or graphing program, the effect of a graph-paper
background consisting of major/minor lines or dots is most efficiently
created by the repetition of tiles that contain atleast one major line/dot,
and a set of minor lines/dots. It also minimizes the size of any backing
pixmap stored in the server.

> 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.