bewing wrote:
To some extent I agree with Avarok, but mystran made good points. However, the one big problem I see is when your abstracted GUI device context points to something other than a screen. Like a printer. Printers do not have windows to invalidate (or even events to a large extent) -- but you typically do need to draw on them in exactly the way you would to a screen device context. mystran's mechanisms seem well adapted to creating efficient screen drawing, but would involve painful contortions to do printer drawing. It seems a much bigger trick to efficiently handle both, without doing painful contortions for either.
I don't see why anyone would want to print GUI elements (which is what windows on screen should represent). Sure, you might want to print a document, but it's not THAT hard to have a document, which knows how to render itself, then have a window, which knows how to put itself on the screen and appear responsive, handling invalidations and such, and then have a menu entry, which starts a printing thread, which asks for the document to render itself just like the window would, but for the printer.
Added benefit is you get background printing essentially for free (well, if you don't want it, just call the printing methods directly, but that sucks).
Anyway, printing and screen display are different anyway. Don't forget the resolution difference between around ~100 dpi for screen vs. 600dpi for average printer, yet dumping that much pixels to printer is just stupid, so you mostly let the printer do the rasterization from vectors unless you need to print an image that happens to be bitmap to start with, or have a really really stupid printer (in which case the drivers will rasterize for you anyway). On the other hand, for screen you generally need some anti-aliasing measures, which is usually not that great idea for a printer.
So ... if enforcing proper invalidation processing also prevents people from drawing to screen and printer with the same codepath, I'd say that's just another Good Thing.
Oh, and yeah, I know there are libraries and APIs that let you draw vector data to screen directly, and handle the printer/screen differences for you, but even then I don't see why can't you put the drawing logic into a separate function you call from both your window draw-event code, and your printing code. Such code is still logically part of the document, not a window.