Make height and width inferrable for (abstract) CairoSurface

[timholy]

Gtk.jl and other libraries have containers with fields that are
typed abstractly as ::CairoSurface. This allows width and
height to be inferrable even for the abstract type.
It enforces an "interface" expected of all CairoSurface subtypes.

[timholy]

@lobingera, if you're fine with saying goodbye to appveyor, don't forget to delete the webhooks (Settings -> web hooks).

[lobingera]

LGTM (although i wonder what the usecase is ...), web-hooks to appveyor deleted.

[timholy]

although i wonder what the usecase is

Marginally better performance with Gtk (since Gtk doesn't store which kind of CairoSurface it is), but the real benefit is better precompilability and thus lower latency on first use. See JuliaLang/www.julialang.org#1111 and a preview at https://julialang.netlify.app/previews/pr1111/blog/2021/01/precompile_tutorial/.

This is a very small change and thus it has only small impact (you wouldn't notice anything from this change by itself), but it's one of a long list from tracking down sources of inference failures in my soon-to-be-released GtkObservables package.

[timholy]

Oops, though I see I messed up this test...fixed in #339.

[lobingera]

I see. But; as far as i understand, the width and height stored in the surface type are more informative and the dimensions of create surfaces - not necessariiy how the data is arranged in memory (see stride information in https://www.cairographics.org/manual/cairo-Image-Surfaces.html). And your comment about "Gtk doesn't store which kind of CairoSurface it is" - i don't think Gtk offers more than the CairoContext in case of widget (re-)drawing and afair in cases of redrawing you get clipping, but not more information. So deriving width+height from Context -> Surface for rendering on screen (and your definitions for precomp for user_to_device is another indication...) might work in some cases, but not in the general case with e.g. overlapping windows.