export {Start,End}GraphicsExposures from x11drv

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at 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:
>   1. Fundamental operations: the driver _has_ to define those
>      For example, for a graphics driver those would be: [gs]et pixel/bitmap
>   2. 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.

-- 
Alexandre Julliard
julliard at winehq.com