Hi
Here are some ideas for optimizing our gdi object code:
1.) When allocating, locking and deleting a gdi object, we pass the
global variable GdiHandleTable to GDIOBJ_AllocObj(). Do we really need
this? Is there a case where we pass something else? We would only save
few cycles here, but if we don't need it...
2.) When allocating a gdi object, we first need to search the list of
LookasideLists. My suggestion is to give each gdi object type a constant
index in the list and pass that index instead of the object type value.
That would require that the table for the object types/sizes/CleanupProc
is in sync with the index definitions. This could be achieved by
initializing that table on win32k load:
InitGdiObjectType(UINT Index, LONG GdiType, ULONG_PTR ObjectSize,
GDICLEANUPPROC CleanupProc);
Then we only need to make sure, that every index is only there once and
add one line for each object in GDIOBJ_iAllocHandleTable to initialize
the object type.
3.) ROS makes massive use of gdi object handles. It uses a lot more
handles than windows does. That is because every object we use is always
inserted into the handle table. This is slow and wastes handle entries,
wich are a limited resource. Whenever we need a (temporary) object, we
allocate it (find lookaside list, allocate mem, find free entry, lock
entry, do some stuff, unlock entry), then in a second call lock it (do
some checks, lock entry, return pointer) and at the end unlock it and
then delete it.
I think we should rewrite the code a little, so that we only create
handles, when the object reaches usermode and use pointers to mem
objects instead if the objects are kernel mode / temporary only.
XXXOBJ_AllocObj(UINT Index) -> allocate an entry from the LookasideList
and initialize it. Don't create a handle.
XXXOBJ_FreeObj(PVOID pObjBody) -> free the entry from the LookasideList
GDIOBJ_CreateHandle(PVOID pObjBody, UINT Index, LONG GdiType) -> create
a handle for a given mem object
rewrite some XXXOBJ_Xxx apis to deal with pointers to the mem objects
instead of handles (see REGION_Xxx apis)
Imo this should result in a big speed increase for several ntgdi/ntuser apis
Regards,
Timo