We currently use a moz_cairo_set_target(cairo_surface_t*) hack to get our double buffering to work; we should be using push/pop group to double buffer.

Like so. This only fixes win32 native themeing; separate patch for linux native theme coming shortly. Some issues that need to be addressed later once we have the cairo support: - gfxUnknownSufrace should go away once we can get the actual cairo surface type from cairo. - the call to cairo_win32_surface_get_dc() should be wrapped on gfxWindowsSurface (depends on the above) - We may want to combine CurrentSurface() and CurrentGroupSurface() such that CurrentSurface() always returns wherever drawing is happening right now, and add a separate GetTarget() to return the original target. - We still need a cairo method to force an update of the clip to the backend; new_path(); rectangle(0,0,0,0); fill(); is working fine for now, but it's a gross hack. We may want to wrap that in thebes, actually, so that we can just replace it in one place when we can.

(In reply to comment #1) > - We still need a cairo method to force an update of the clip to the backend; > new_path(); rectangle(0,0,0,0); fill(); is working fine for now, but it's a > gross hack. We may want to wrap that in thebes, actually, so that we can just > replace it in one place when we can. I hope that with my approach to native theme drawing, this won't be necessary at all, because we won't be relying on cairo to set the native clip.

Hopefully that'll be true; we can just use the cliprect passed in to the native theme drawing functions? I wasn't sure if that could be trusted or not, since it wasn't being used right now. Also, from looking at the linux side of things, this will be a pain to implement on linux and will probably duplicate a part of your work. What do you think about just disabling native theme on linux temporarily until your changes land?

sure, disable native themes on linux. I will reintegrate and reenable.

(In reply to comment #3) > Hopefully that'll be true; we can just use the cliprect passed in to the > native theme drawing functions? I wasn't sure if that could be trusted or > not, since it wasn't being used right now. On Linux, I don't trust the native theme to honour any clipping in some cases where I know important themes don't :-). I have logic to handle this in a reasonable way. I still know some bounds outside which the theme is guaranteed to not draw, and if those bounds are entirely inside the current cairo clip, then there is no need to worry. In the worst case where clipping is necessary and I can't trust the theme to clip, I go through a temporary surface. On Windows, if we don't trust the theme, we could just set a clip rect in the DC before passing it to the theme. Because I have added cairo clip getters, I can figure out what that rect (if any) should be.

Note that the temporary-surface fallback for clipping is absolutely necessary when cairo is using a clipping mask surface.