[ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation...

[Timo Kreuzer]

NtGdiBitBlt calls IntEngBitBlt, wich calls DrvBitBlt if available. 
There's no DrvScroll function.

Timo
> Author: weiden
> Date: Fri Oct 19 07:23:04 2007
> New Revision: 29670
>
> URL: http://svn.reactos.org/svn/reactos?rev=29670&view=rev http://svn.reactos.org/svn/reactos?rev=29670&view=rev
> Log:
> Tweak the ScrollDC implementation a bit so that it produces a better output. The implementation still is completely incorrect as it should call the driver for this operation instead of doing a BitBlt operation...
>
> Modified:
>     trunk/reactos/subsystems/win32/win32k/ntuser/painting.c

[James Tabor]

Hi!
BTW, I found my old notes again. 8^)

After some research over the years, I found out there are up to 8 or more
WndProc atom classes registered in win32k and not user32.

Integer Atoms:
#define POPUPMENU_CLASS_ATOM MAKEINTATOM(32768)  /* PopupMenu */ Reg in W32k
#define DESKTOP_CLASS_ATOM   MAKEINTATOM(32769)  /* Desktop */   Reg in W32k
#define DIALOG_CLASS_ATOM    MAKEINTATOM(32770)  /* Dialog */    Reg in User32
#define WINSWITCH_CLASS_ATOM MAKEINTATOM(32771)  /* WinSwitch */ Reg in W32k
#define ICONTITLE_CLASS_ATOM MAKEINTATOM(32772)  /* IconTitle */ Reg in W32k

#define TOOLTIP_CLASS_ATOM MAKEINTATOM(32774) Reg in W32k

String Atoms:
"ScrollBar", "Message", and something called "DDEMLEvent" for WM_DDEMLEVENT.

The one that we are looking into fixing "ScrollBar", The controls are in
win32k and not in User32.

I noticed WndProc messages originate from win32k too. The window thread is
locked and then the message is sent out.

Example: Function call User32 -> Win32k -> send message.

Maybe we are doing double the work when we scroll on a bar. The rapid
blinking of the bar too. We maybe sending more than one message out.

Example: Win32k send message, then in the loop, user32 sends the same message
back into Win32k we go and loop again, wow!

We have scroll controls in user32 and we are controlling the scrolling from
win32k. It just look so messy!

So~

Once Gdi/Win32k is at a state of normality and acting like it should. We need
to setup a game plan for User/Win32k.

1. Map View the Wnd handle table and Wnd objects to user process space
   (readonly), like gdi.
    a. This will allow user space to read the table and read the WINDOW_OBJECT.
2. Migrate the above atom classes and controls to win32k.
3. Add more. .. ....
4. Fix bugs.
5. Get paid!

Thanks,
James

http://wiki.winprog.org/wiki/Windows_messages
http://msdn2.microsoft.com/en-us/library/ms997511.aspx

[James Tabor]

Hi!
Oh, another reason to move them into Win32k; You can not write to the
Window Object in user mode.

Window object are read only and ATM we do not support it. We have code
trying to do it but it does not work yet.

Thanks,
James

On Oct 27, 2007 1:21 AM, James Tabor
[e-mail] wrote:
> Hi!
> BTW, I found my old notes again. 8^)
>
> After some research over the years, I found out there are up to 8 or more
> WndProc atom classes registered in win32k and not user32.
>
> Integer Atoms:
> #define POPUPMENU_CLASS_ATOM MAKEINTATOM(32768)  /* PopupMenu */ Reg in W32k
> #define DESKTOP_CLASS_ATOM   MAKEINTATOM(32769)  /* Desktop */   Reg in W32k
> #define DIALOG_CLASS_ATOM    MAKEINTATOM(32770)  /* Dialog */    Reg in User32
> #define WINSWITCH_CLASS_ATOM MAKEINTATOM(32771)  /* WinSwitch */ Reg in W32k
> #define ICONTITLE_CLASS_ATOM MAKEINTATOM(32772)  /* IconTitle */ Reg in W32k
>
> #define TOOLTIP_CLASS_ATOM MAKEINTATOM(32774) Reg in W32k
>
> String Atoms:
> "ScrollBar", "Message", and something called "DDEMLEvent" for WM_DDEMLEVENT.
>
> The one that we are looking into fixing "ScrollBar", The controls are in
> win32k and not in User32.
>
> I noticed WndProc messages originate from win32k too. The window thread is
> locked and then the message is sent out.
>
> Example: Function call User32 -> Win32k -> send message.
>
> Maybe we are doing double the work when we scroll on a bar. The rapid
> blinking of the bar too. We maybe sending more than one message out.
>
> Example: Win32k send message, then in the loop, user32 sends the same message
> back into Win32k we go and loop again, wow!
>
> We have scroll controls in user32 and we are controlling the scrolling from
> win32k. It just look so messy!
>
> So~
>
> Once Gdi/Win32k is at a state of normality and acting like it should. We need
> to setup a game plan for User/Win32k.
> Map View the Wnd handle table and Wnd objects to user process space
> (readonly), like gdi.
>  a. This will allow user space to read the table and read the WINDOW_OBJECT.
> Migrate the above atom classes and controls to win32k.
> Add more. .. ....
> Fix bugs.
> Get paid!
>
> Thanks,
> James
>
> http://wiki.winprog.org/wiki/Windows_messages
> http://msdn2.microsoft.com/en-us/library/ms997511.aspx
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev