"Dimitrie O. Paun" dpaun@rogers.com writes:
Fundamentally, the main purpose of a USER driver is to deal with windowing, and as such, it needs to be able to compute invalidated areas. It thus makes sense to for it to export functions that let you query this information.
The start/end interface used by x11drv makes sense, and it looks sane enough to be exported.
I disagree. Graphics exposures are a very X11 specific concept, they don't belong in the generic driver interface. This kind of change leads to the approach that we used before: do everything in USER and add a few strategically placed calls to x11drv where we really need it. That's the wrong approach, because it cannot be adapted to other drivers except by adding more and more driver calls all over USER.
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. Of course reconciling that with dll separation is not always trivial, but that's part of the fun...
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?
"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.
On September 23, 2002 03:42 pm, Alexandre Julliard wrote:
is making available. That's why the right approach is to follow the API closely.
Closely, yes, but not necessarily exactly. There are clearly things in the API that are not the business of the driver, but I agree with you that are far in between. BTW, I did not dispute this point :)
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.
But that's *EXACTLY* my point! This is a fundamental job of the USER driver, why would it be bad to expose it? But this is all academic anyway, if you don't want to have a fallback until later on...
"Dimitrie O. Paun" dpaun@rogers.com writes:
But that's *EXACTLY* my point! This is a fundamental job of the USER driver, why would it be bad to expose it?
It is exposed, only not with such a specific interface. The driver functions like ScrollWindow and ShowWindow implicitly request the driver to perform exposure processing too. But making that request explicit is not really possible except with major overhead. For instance you'd have to split ShowWindow into a "show" call and then a separate "process exposures" call which would need to redo most of the work to find out what the previous "show" call did. It's much better to have a single call doing both, so that the driver can do exposures processing at the point where it makes the most sense.
On September 23, 2002 04:19 pm, Alexandre Julliard wrote:
instance you'd have to split ShowWindow into a "show" call and then a separate "process exposures" call which would need to redo most of the work to find out what the previous "show" call did.
This is not necessarily so. That's why you have a Start/End pair. It lets you collect the exposure events that happen between the two brackets.
But regardless, I was looking at ShowWindow, and I don't understand what is it doing in the USER driver. It's just a wrapper arount SetWindowPos (which should be in the driver). Why have this one in there in the first place? The driver has to implement the functionality in SetWindowPos anyway, it can not do a better job for ShowWindow. Even if it can, the current implementation should be as a fallback in USER, not in the driver.
"Dimitrie O. Paun" dpaun@rogers.com writes:
This is not necessarily so. That's why you have a Start/End pair. It lets you collect the exposure events that happen between the two brackets.
Then you force the driver to collect them for the End call, which in many cases is not necessary (especially since USER is already collecting them in the update region). Or you allow the driver to do exposures at any time, and you don't need the Start/End. Either way it's not a good interface.
But regardless, I was looking at ShowWindow, and I don't understand what is it doing in the USER driver. It's just a wrapper arount SetWindowPos (which should be in the driver). Why have this one in there in the first place? The driver has to implement the functionality in SetWindowPos anyway, it can not do a better job for ShowWindow. Even if it can, the current implementation should be as a fallback in USER, not in the driver.
ShowWindow does a lot more than SetWindowPos. It handles minimize/maximize which needs to interact with the window manager (it does this pretty badly at the moment but this will be fixed, and can only be fixed precisely because ShowWindow is now in the driver).
On September 23, 2002 04:54 pm, Alexandre Julliard wrote:
Then you force the driver to collect them for the End call, which in
But of course, you called Start! If you don't want them collected for the end call, don't start collecting them... :) I really see these as: tell me what gets invalidated between these two calls.
In fact, I don't think it's such a big deal: they are used only by ScrollWindowEx, we might as well just implement it in the driver, and have no fallback. I guess I was just trying to understand (as an academic matter) why you think we shouldn't be able to ask the USER driver what got invalidated when doing stuff...
ShowWindow does a lot more than SetWindowPos. It handles minimize/maximize which needs to interact with the window manager
Good point. I missed that -- I looked at the implementation, instead of the definition <blush/>. It clearly belongs in the driver.
"Dimitrie O. Paun" dpaun@rogers.com writes:
But of course, you called Start! If you don't want them collected for the end call, don't start collecting them... :) I really see these as: tell me what gets invalidated between these two calls.
But the point is that this is not necessarily the right model from the driver point of view. By calling Start, USER forces the driver to use an "accumulate until End" model which may not be the best one for the given operation; but this is something that the driver knows, not USER.
The current approach is that the driver pushes exposures into USER whenever it feels it necessary. Your approach is to make USER pull exposures out of the driver when USER thinks that it should be needed. The problem is that the one who knows when there is a need for exposures is the driver, not USER, so the push model is much more appropriate (even more so with X11 asynchronous events, where you can't predict when exposures happen).
On September 23, 2002 05:54 pm, Alexandre Julliard wrote:
But the point is that this is not necessarily the right model from the driver point of view. By calling Start, USER forces the driver to use an "accumulate until End" model which may not be the best one for the given operation; but this is something that the driver knows, not USER.
I understand that. That's why I've left in my patch the pScrollWindowEx around, in case the driver thinks it can do a better job. We don't lose the ability to do a superjob on ScrollWindowEx. But if we don't feel like it, we have a fairly good fallback (in fact, it's quite good as it does what the x11drv does now :)).
However, I don't think this is important. With the current setup, we either have to implement ScrollWindowEx or (with my patch) the {Start,End}GraphicsExposure in driver, and it's not obvious that one is simpler to implement than the other. The approach of exposing {Start,End}GraphicsExposure would make sense if we could provide a fair number of _decent_ (not optimal) fallbacks for the driver. Than you could simply implement the {Start,End}GraphicsExposure to get the driver off the ground (which, I figured, you'd need internally anyhow).
-
Alexandre Julliard -
Dimitrie O. Paun