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