It’s worth a try, though (currently) it’s only a compile-time flag. We could do something to help things switch even better at runtime
Works fine in Windows 10 
Ok, thank you for clarification!
Unfortunately, –window-hardware=false makes my game super slow. 
I tested Lime in Windows XP (x64 edition) and found a simple GL application worked, but using Cairo with an image surface crashed. Something within Cairo, I suppose. OpenFL relies upon Cairo support, even in GL projects (for shapes, etc) so we do not support Windows XP right now. I wonder how many people are using it? With help, it may be possible to get things running there, but I’m unsure we can’t just focus on newer versions of the OS?
I think that you can read crash dump to see what’s happening there. Without that it’s pretty difficult.
It occurs on Cairo paint, when using an image surface (like DisplayingABitmap does). It does not fail if it is, say, just a solid color, like the Lime HelloWorld sample. After cairo_paint, it delves deep into the Cairo internals, so maybe we need to compile Cairo differently, or there’s a bug in there, or it does not work with regular CairoImageSurface objects…?