Bug 29295

For reference, we have such a function for X11 backend.  Please check for consistency if it makes sense.

(In reply to comment #1)
> For reference, we have such a function for X11 backend.  Please check for
> consistency if it makes sense.

Yep, I know, that's why I figured we should have it on Quartz (perhaps win32) as well:

void
cairo_xlib_surface_set_size (cairo_surface_t *abstract_surface,
                             int              width,
                             int              height)

Does it make sense at all?
Quartz surfaces can't actually change their extents.
What is that function supposed to do?

(In reply to comment #3)
> Does it make sense at all?
> Quartz surfaces can't actually change their extents.
> What is that function supposed to do?

Wait, I might have misunderstood a part here.  Are Quartz surfaces always backed by a CGBitmap with a memory buffer for a fixed width, height?

(I was under the impression that Quartz surfaces were unlimited in size for some reason, and modifying the extents made things work here, but perhaps it was just writing outside memory bounds?).

(In reply to comment #4)
> (In reply to comment #3)
> > Does it make sense at all?
> > Quartz surfaces can't actually change their extents.
> > What is that function supposed to do?
> 
> Wait, I might have misunderstood a part here.  Are Quartz surfaces always
> backed by a CGBitmap with a memory buffer for a fixed width, height?
No, they can also be backed by any CGContext. In this case some operation will fail (example: operator SATURATE), but they should mostly work.
> 
> (I was under the impression that Quartz surfaces were unlimited in size for
> some reason, and modifying the extents made things work here, but perhaps it
> was just writing outside memory bounds?).
AFAICT all CGContext implementations seem to have a fixed size. Even in your use case I would expect you to invalidate the old surface (since it has an incorrect size) and create a new one.

(In reply to comment #5)
> > (I was under the impression that Quartz surfaces were unlimited in size for
> > some reason, and modifying the extents made things work here, but perhaps it
> > was just writing outside memory bounds?).
> AFAICT all CGContext implementations seem to have a fixed size. Even in your
> use case I would expect you to invalidate the old surface (since it has an
> incorrect size) and create a new one.

Ok, I guess the resizing worked by accident then ;)   We will take the surface re-creation route then, which indeed seems the best way.

Thanks for the help, sorry for the noise.

If you didn't create the CGContext yourself (in which case I would expect it to be a CGBitmapContext or something whose size is known to be constant anyway), I can probably assume safely that you're using a context that you got from Cocoa. Please notice that cocoa graphic context are not valid anymore as soon as you return from the drawing function, or, as Apple example says (http://developer.apple.com/mac/library/samplecode/JAWTExample/Listings/NativeDrawnCanvas_m.html): "DO NOT CACHE NSGraphicsContexts -- they may go away."

I can't find a similar statement in the documentation, only in the examples, but anyway I would consider it a good reason for the safe way (context recreation).