Hi It is good idea doing it.
I am thinking we should using the internal document structs for win32k that he did for directx instead using my home mades ones. It does not redures the overheade,
Next issue I got is the EDD_SURFACE (see Windows Graphics Programming Win32 GDI and DirectDraw chapther 3.9 ) it contain value for iVisRgnUniqueness, but this value are share memory with gdi32.dll, Here is why we need implement it to gdi share memory or some other way it is done ?.
Todo a DirectDraw/D3D/DirectX graphicing drawing/D3D we need always rest the iVisRgnUniqueness before we calling DdBlt or other graphice drawing api if we whant it show on the screen. other wise nothing will show or happen. This is not true for few graphice cards drivers, But it is true for ATI, S3 and allot other but not for few other, driver. The iVisRgnUniqueness are global in win32k, I meaing it is same for all surface. so it change very often in DirectX, and causing allot of context switch if we should using the NtGdiDdResetVisrgn. Microsoft known they self it is madess doing extra context switch for it. that so they decide doing it in user mode,
The question is, are this value really in gdi32 share memory or do they doing it some other way. And I have not figout that out, only it is done in user mode in windows nt all version. The Yang book Windows Graphics Programming Win32 GDI and DirectDraw does not mentor this either.
----- Original Message ----- From: "James Tabor" jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net To: "ReactOS Development List" ros-dev@reactos.org Sent: Friday, July 27, 2007 9:10 PM Subject: [ros-dev] Win32/Gdi32 rewrite
Hi all, I'm giving in to the idea of having two dc_attrs.
From, Windows Graphics Programming Win32 GDI and DirectDraw -> 3.8 GDI
KERNEL MODE DATA STRUCTURE ->
Device Context in the GDI Engine, second to the last paragraph:
Field pdcattr points to the DC_ATTR structure for that device context in
user mode address space,
which contains most device context settings. The DCOBJ structure has a
duplication of it in its
dcAttr field. It's possible the GDI designers want setting DC attributes
to be efficient, with as
little kernel mode code involvement as possible. This requires a DC_ATTR
structure in user mode. But
they also want to be able to access it easily in kernel mode, which
requires a copy of DC_ATTR in
kernel mode. Certain flags may be used to synchronize the two copies of
DC_ATTR.
typedef struct { // ......snip...... void * pdcattr; // point to user mode DCATTR DCLEVEL dcLevel; // 0x030 0x1B8(440) bytes DC_ATTR dcAttr; // 0x1C8(456) bytes // ......snip...... } DCOBJ;
I did set up Ros DC structure to have the dc_attr pointer stored. I guess
it's time to move the old
WIN_DC_INFO stuff over to the new kernel mode dc_attr and use the dirty
flags for synchronizing.
This will fix my memory access problems too. I did an experiment to test
the idea of just copy if it
was dirty and all my problems went away.
FYI, James
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev