Hi All,
I am working with display driver. I went through some of the concepts of display driver. what i looked is “GENERALLY” GDI32 calls from user application will be replicated by kernel mode GDI calls (ENG* calls), if this calls are just replica of ENG* calls then how display driver is more faster than simple GDI32 calls? and yes, concepts says that display driver is more faster than any other mechanism to capture screen data but how???
Thanks,
Ravi.
There’s no way your display driver can implement those functions any
faster than GDI can. The GDI routines have been optimized over the
course of the last fifteen years. (Actually, you probably can beat a
few of them, but on the whole, probably not.)
That’s not the point. The reason that your display driver is being
given the chance to implement those routines is that, presumably, your
display hardware has some ability to perform many of those primitive
operations in hardware. Thus your display driver can beat GDI by
using a special purpose drawing engine on your chip.
As an example, look at BitBlt. You probably have hardware that can
move a rectangle from one part of display memory to another much more
cheaply than the main processor could copy it. (If you don’t, get the
hardware people to add that.) So hook the routines that do blits and
let your hardware shine.
When your particular chip can’t accelerate an operation, punt it to
GDI and let it do the work.
If, by the way, you are writing some sort of display driver that
doesn’t correspond to actual hardware, then you’ll probably want GDI
to do all the drawing for you. Don’t hook anything.
wrote in message news:xxxxx@ntdev…
> Hi All,
> I am working with display driver. I went through some of the
> concepts of display driver. what i looked is “GENERALLY” GDI32 calls
> from user application will be replicated by kernel mode GDI calls
> (ENG* calls), if this calls are just replica of ENG* calls then how
> display driver is more faster than simple GDI32 calls? and yes,
> concepts says that display driver is more faster than any other
> mechanism to capture screen data but how???
>
>
> Thanks,
> Ravi.
>
How i can get screen data from mirror driver?
Hi All,
I looked into IOCTLs document and i got how to transfer data from user mode to kernel mode.I want to create mirror driver and i am totally new to mirror driver development. can anybody tell me that how can i collect screen data from driver(which structure will give me this information?) so i can use it in user application?
Ravi.
xxxxx@einfochips.com wrote:
I looked into IOCTLs document and i got how to transfer data from user mode to kernel mode.I want to create mirror driver and i am totally new to mirror driver development. can anybody tell me that how can i collect screen data from driver(which structure will give me this information?) so i can use it in user application?
This was discussed ad nauseum on this mailing list last fall. A search
of the archives would be fruitful.
The mirror driver will be completely under your control. YOU need to
decide what information you need to share with user mode, and then you
need to use one of the standard techniques to send it to user mode.
You can’t send ioctls to a display driver. You can, however, make
ExtEscape calls. The mirror driver can call into its miniport, and the
miniport can use arbitrary normal kernel-mode APIs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sorry Tim, yes we have to use Escape codes rather than IOCTLs to communicate with display driver. but from where i can get the screen data in driver? how ?
EngXxx calls are the software-only (no GPU) implementation of the GDI
driver which supports all STYPE_BITMAP surfaces.
For the driver writer, it is like a C++ base class - the driver’s routine
(DrvXxx) can call the “base class routine” of EngXxx to do the work. More so,
if DrvXxx always contains 1 single call to EngXxx, then you can just omit
DrvXxx and GDI will substitute EngXxx instead itself.
DrvXxx are intended only to employ the GPU (if any). The usual DrvXxx code
is - a) check whether this operation with these parameter values can be
executed by GPU b) if yes - program the GPU, run the operation by GPU and quit
c) if no - then call EngXxx as a “base class method”.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi All,
> I am working with display driver. I went through some of the concepts
of display driver. what i looked is “GENERALLY” GDI32 calls from user
application will be replicated by kernel mode GDI calls (ENG* calls), if this
calls are just replica of ENG* calls then how display driver is more faster
than simple GDI32 calls? and yes, concepts says that display driver is more
faster than any other mechanism to capture screen data but how???
>
>
> Thanks,
> Ravi.
>
The primary purpose for display driver is to deliver the os rendering primitives to the GPU, the GPU then renders. Even a lousy GPU can easily beat GDI.
–
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
wrote in message news:xxxxx@ntdev…
> Hi All,
> I am working with display driver. I went through some of the concepts of display driver. what i looked is “GENERALLY” GDI32 calls from user application will be replicated by kernel mode GDI calls (ENG* calls), if this calls are just replica of ENG* calls then how display driver is more faster than simple GDI32 calls? and yes, concepts says that display driver is more faster than any other mechanism to capture screen data but how???
>
>
> Thanks,
> Ravi.
>
xxxxx@yahoo.ca wrote:
The primary purpose for display driver is to deliver the os rendering primitives to the GPU, the GPU then renders. Even a lousy GPU can easily beat GDI.
That’s not as true as it once was. CPUs are unbelievably fast today,
much faster than the clocks on low-end GPUs
X.Org on Linux, for example, has an easy way to bring up X using a
“frame buffer” driver, which bypasses the graphics accelerator and
treats the frame buffer as a big, dumb pile of bits. In many cases, the
performance using the frame buffer driver is practically as good as it
is with the accelerator. Big patterned fills and window moves tend do
to be an issue.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@einfochips.com wrote:
Sorry Tim, yes we have to use Escape codes rather than IOCTLs to communicate with display driver. but from where i can get the screen data in driver? how ?
Look, that’s entirely up to you. Your mirror driver has to maintain the
surface, you have to decide what data you need to get to user mode, and
how to get it there. We don’t know what kind of data you want to send,
how much of it there will be, or what you intend to do with it.
There are lots of options for communication: polling with an escape
code, using an in-memory buffer, using a memory-mapped file, etc. Only
you know your requirements.
Again, however, do not discard the option of using the DemoForge mirror
driver, which is fully functional and well-tested.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, I am just try to develop desktop sharing application. When system perform drawing operation it draws also on mirror driver. Now i am interested in area that is drawn by system on mirror driver. At which point in mirror driver i can found area that is rendered on mirror driver? so i can notify the user application with that area information?
Ravi,
You get equivalent drawing calls in your mirror driver as a real display driver.
So the parameters of those calls give you dirty area, I mean the area on which data should be written.
You will be having control of the surface on which drawing happens wrt your mirror driver.
Hi Sunil,
Can you please tell me the functions that are called by system to gives these dirty area?
xxxxx@einfochips.com wrote:
Hi Sunil,
Can you please tell me the functions that are called by system to gives these dirty area?
Have you even looked at the sample mirror driver in the SDK? Have you
stepped through it with a debugger?
When an application calls BitBlt, GDI will translate that into DrvBitBlt
calls into whatever display drivers are present: usually the main
display driver(s), but also a mirror driver, if present. So, your
mirror driver (when installed) will receive a DrvBitBlt call. The
parameters to the DrvBitBlt call include the source and destination
rectangles for the blt operation (plus pattern and mask and clipping
rectangle etc). It should be clear that the “destination rectangle” is
the one that will change. The same thing applies to DrvCopyBits,
DrvTextOut, DrvStrokePath, DrvFillPath, and all of the other driver
calls that can change the surface. Using the parameters, you have to
FIGURE OUT which areas are going to change.
Also remember that you still have to DO the drawing. A mirror driver IS
a display driver. You are not just piggy-backing on another driver.
You have your own surface, and you have to do the drawing on that
surface (or, at least, ask GDI to do it for you with Eng calls).
There seems to be a general sense that this should be an easy job. It
is NOT. There are a lot of details to worry about. That’s why it would
behoove many people to take a close look at DemoForge’s DFMirage. It is
designed for this task: a general-purpose mirror driver for monitoring
changes to the frame buffer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.