export {Start,End}GraphicsExposures from x11drv

[Dimitrie O. Paun]

On September 23, 2002 02:25 pm, Alexandre Julliard wrote:
[I knew I'm gonna have problems with this one... :)]

> The new approach is to put the driver in charge as much as possible;
> this means a lot more work is done inside the driver functions, which
> in turn gives a lot more flexibility.

I understand the new approach, and it's certaily the right one. However,
having the driver implement a given function 100% in terms of USER&GDI,
doesn't make much sense either. It just means it doesn't know anything
special about the operation.

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.

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.

But I don't think there is much disagrement here. The big question for
this patch is if it exposes too much of the internals of the driver.
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?

-- 
Dimi.