"Dimitrie O. Paun" dpaun@rogers.com writes:
Look, when we have a driver interface, we have to think what is it that the driver has to do, what it drives, and what needs to know. We have to figure out what funcdamental operations it _has_ to provide, and what it can possibly provide as an optimized operation. The interface to the driver need not be strictly the same as the Win32 functions. In fact, it most likely is not a perfect super/subset of those.
The interface cannot really be a superset of the API, you can't have the driver somehow require more information than what the application is making available. That's why the right approach is to follow the API closely. If ScrollWindow maps to driver->ScrollWindow with the same parameters, you know it can work, because all the information we have is made available to the driver. If you start restricting what you pass to the driver you have no idea if you restricted to the right subset for all present and future drivers.
What I am getting at is that we need to define:
- Fundamental operations: the driver _has_ to define those For example, for a graphics driver those would be: [gs]et pixel/bitmap
- Optional operations: these are typically close to Win32 functions For examlpe, draw a rectangle
The optional operations need to have fallback implementations in USER/GDI. There's really no point in having some drivers have 100% exact implementations for some of the optional operations: it's just code duplication.
Yes it is duplication, but it is necessary to have the flexibility. And until someone needs the fallback in USER there's no need to implement it anyway.
It is my understanding (and please correct me if I'm wrong), that a USER driver is mainly meant to deal with windowing, right? Well, in that case, it _fundamentally_ has to be able to figure out exposure events. Yes, the terminology is X11 specific, but the *concept* is not, by no means. I can invent other terminology, but what would be the point?
The concept of ScrollWindow is that the window is scrolled and properly refreshed, that's all. There is nothing in the concept that says you can always do it with start/end calls, or that the driver needs an HDC and not an HWND or a rectangle, etc. And figuring out exposure events fundamentally has to be the job of the driver, because there are other windows on the screen that USER doesn't know about. USER provides the mechanisms to expose windows (RedrawWindow etc.), but using them is in general the responsibility of the driver.