Re: [ros-dev] Win32/Gdi32 rewrite

[Magnus Olsen]

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(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
To: "ReactOS Development List" <ros-dev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev