gdi32 : Questions about SetDIBColorTable and GetDIBColorTable
Hi, I am looking deeper inside gdi32 in order to continue helping wine after my first try on WidenPath. Something looks strange to me in SetDIBColorTable and GetDIBColorTable. GetDIBColorTable is structured like this : if (dc->funcs->pGetDIBColorTable) result = dc->funcs->pGetDIBColorTable; else { result = local implementation; } return result; This looks normal. If dc->funcs->pGetDIBColorTable is available, wine uses it, else it uses a local implementation. In both cases, the return value is the result of the chosen operation. But I have more difficulties with SetDIBColorTable : result = local implementation; if (dc->funcs->pGetDIBColorTable) dc->funcs->pGetDIBColorTable; return result; Whatever happen next, the local implementation is used. Then if pGetDIBColorTable is available, it is used too. I see here a second call for the same thing, even if the local implementation succeed. Moreover, the result of dc->funcs->pGetDIBColorTable is not used as a return value. Is there a mistake here, or is there something I do not understand ? GetDIBColorTable uses the local implementation only if dc->funcs is not available. That is not the case for SetDIBColorTable, which runs first the local implementation. What is the right policy to apply here ? I believe the call order of pSetDIBColorTable and the fact its return value is not used are errors. Am i wrong? If someone can confirm I am not, I will provide a patch in the next days. Thank you for your help and time, Laurent Vromman
Laurent Vromman <laurent(a)vromman.org> writes:
Whatever happen next, the local implementation is used. Then if pGetDIBColorTable is available, it is used too. I see here a second call for the same thing, even if the local implementation succeed. Moreover, the result of dc->funcs->pGetDIBColorTable is not used as a return value. Is there a mistake here, or is there something I do not understand ?
GetDIBColorTable uses the local implementation only if dc->funcs is not available. That is not the case for SetDIBColorTable, which runs first the local implementation. What is the right policy to apply here ?
Both are correct. gdi32 always stores the color table, so it has to be updated upon SetDIBColorTable no matter what the driver does; while GetDIBColorTable doesn't need to access it if the driver has a better way of doing it. This way the driver can either: 1. not implement anything, get and set are handled by gdi32; 2. let gdi32 maintain the local copy but still do something when the color table is changed; 3. implemented both set and get to override gdi32 completely. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Laurent Vromman