Is this worth the effort?

[tannerhelland]

Sorry for the stupid issue title, but I wasn't sure how else to phrase this. I just noticed this project today and wanted to offer some thoughts before too many talented people spend time on a porting effort that IMO isn't worth it.

I have spent the past few months comprehensively perf-testing Cairo against GDI+. In nearly every area where the two libraries overlap (which is 90+% of features), GDI+ is preferable from a performance standpoint. This isn't surprising, given that Cairo's Windows backend largely wraps existing GDI functions whenever applicable. Cairo is also CPU-bound (no GPU features whatsoever) and its SIMD implementations are minimal, just a small subset of raster-blending functions.

While Cairo's stability is excellent, it is ultimately a 15+ year-old API that has been dropped as the primary renderer from most of the major projects that originally used it. (Firefox abandoned it years ago, GIMP has migrated major features to GEGL, etc.)

I have nothing against Cairo - just the opposite, it's a lovely API for certain tasks - but it is IMO a silly choice for VB6 because GDI+ does the same things, only much faster - and perhaps more importantly, easier from an interop standpoint. I think the obsession of certain VB users with Cairo is simply due to RC5 promotions rather than any particular advantage Cairo offers. (And even then, any benefits in RC5 come not from Cairo itself, but from Olaf's effort to package them in a "beginner-friendly way".)

If a coordinated effort is made to support a 3rd-party 2D rendering API from VB6, Skia is a far better choice. Being backed by Google, it is under much faster development, with more modern features and significantly improved performance via modern backends (e.g. Vulkan). Building Skia on Windows is tedious due to reliance on Google-specific build tools and Clang, but no more tedious than a properly working build of Cairo with its copious optional dependencies.

This is just my $0.02. Personally, I think a comprehensive GDI/GDI+ wrapper that abstracts away irritating GDI+ quirks would be a preferable choice for most VB6 devs. Ideally, the wrapper could be implemented in such a way that future backends could be supported via a shared interface (e.g. cSurfaceGDIP and cSurfaceSkia both implement some shared "ISurface" design).

I've been working on such a wrapper for some time and have a fairly battle-tested implementation that is largely complete. (I don't know if its design is good, but it's fast and structured very simply.) I originally planned to implement an alternate Cairo backend, but I recently abandoned these plans upon realizing how pointless it is to invest the extra effort for worse performance - and in some cases, worse quality. MS graphics APIs have never been great, but GDI+ is really quite nicely built for the tasks it covers.

I mention this only because if this is a "high-priority" task for the VB6 community, I would be happy to clean up my implementation and upload it to a clean repository. And if my design is miserably bad compared to what others had in mind, that's okay, I'll happily contribute to their better implementations!

Anyway, I didn't mean to shit on anyone's hard work. :) Thanks as always for developing interesting VB6 projects "in the open".

[wqweto]

10x for input, Tanner!

I'm personally much happier to see the VBForums Community github org coming to life spontaneously. Whether Cairo is the best choice I'm not very convinced too, but the effort to make a thin wrapper is worth it just to get community members involved.

As far as I see it we are aiming here at producing largely unmodified DLL with stdcall calling conventions and BSTR<->UTF-8 string converters, plus a proof-read typelib to access all public exports and enough enums/consts to be able to implement additional OOP wrappers in pure VB6.

Skia binding are coming next! (I just need to put those finishing touches on LLVM:-))

[tannerhelland]

Thanks, Vlad. Your VBLLVM work is extremely cool; I don't think I am alone in watching it excitedly!

While I'm here, I think I'll add $0.02 more. (Wow, so generous of me. lol) In speaking with clients and other VB6 devs over the years, a general consensus seems to emerge that vbforums is... toxic? Largely pointless? 1000:1 ratio of bullshit vs interesting/good work?

Not to shit on them too (although they deserve it, serving logins over plain http in 2018 jfc), but for SEO and community purposes I think it may be preferable to name a "master" community group something like "VB6Community" or similar VB6-focused, to avoid any useless association with a forum that arguably doesn't engender a lot of good will among remaining VB6 devs.

I'm also thinking of things like searching GitHub - how many devs would search "VB6" vs "VBForums"? How would they know VBForumsCommunity isn't VB.NET focused?

Okay, my peanut gallery comments are done for now. I will start cleaning up my 2D VB6 graphics classes, and hopefully have something concrete to contribute in the coming weeks. I would love a generic set of VB classes that I could arbitrarily wrap around GDI+/Skia without rewriting large swaths of code, so consider me very interested in contributing as time allows!

[tannerhelland]

I'm self-closing this issue as "not constructive". ;)

The current thin wrapper is a great contribution and welcome for filling any gaps in GDI/GDI+ coverage, as described by @wqweto above.